Older posts made before the Congo rebranding
In conjunction with New Year 2021 (a landmark year for JavaCC 21 for sure!) I decided to scratch some longstanding itches — even at the expense of introducing some (minor) backward incompatibilities. The various option settings can only be set in the grammar file. There was a longstanding setup in legacy JavaCC (carried forward in …
Happy New Year! Some Backward-Incompatible API Changes! Read More »
One of my longstanding interests is language learning — I mean, human languages like Russian or Chinese, not computer languages. One striking thing about language learning is the extreme variability in people’s results. One observes that certain people, frequently very capable in other fields, will have some ongoing project of learning a language, Spanish for …
When I say "fully supported", I mean all the new features that are categorized as "stable". In fact, the only new language feature that has been promoted to stable in JDK 14 is the new syntax for the Switch statement. This also allows a Switch statement to be used as an expression. In fact, the …
About half a year ago, I wrote a post about ripping out so-called JAVACODE productions. I have to admit that I had almost forgotten about that whole issue (or maybe ersatz issue…) but just now Jan Monterrubio of the JSQLParser project asked me about this and I figured it would be better to answer the …
In the beginning there was… CommonTokenAction Legacy JavaCC had (and still has) a means of applying whatever adjustments (a.k.a. kludges) to a Token just before it is handed off to the parser machinery. You could define a method called CommonTokenAction in your Lexer TokenManager class and this method is invoked when you get another Token …
Not too long ago, I implemented a new syntactical element in JavaCC, that I call the up-to-here marker. To recap: Suppose you have a production like this: FooBar : “foo” “bar” Baz; NB. I am moving towards always just using the newer streamlined syntax in any examples and documentation. For the record, if you really …
Over the last days, I announced certain new features but then realized that they really needed certain key enhancements. I refer to the new FAIL statement and the up-to-here notation, the latter of which I only announced three days ago! The FAIL statement On first implementation, the FAIL statement allowed you to write something like: …
Revisiting LOOKAHEAD Redux Not so long ago, I had a sort of eureka moment when I realized that the legacy LOOKAHEAD construct was fundamentally half-baked or broken. Not only that, but I started narrowing in on how to definitely address the issue! Well, let’s get concrete. Suppose we have a production that looks kind of like this: FooBar : …
New Feature: The =>|| delimiter stands for “scan up to here” Read More »
If you liked LOOKAHEAD, then you’ll love LOOKBEHIND! Actually, I have not added LOOKBEHIND as a new keyword in JavaCC. It is just an informal way of referring to a new feature that I recently added. I implemented this because I realized that there was a very common thing people want to do in a JavaCC grammar …
A few months ago, I started re-examining some of the legacy JavaCC syntax. I realized the pure absurdity of having to write: LOOKAHEAD(Foo() Bar() Baz()) Foo() Bar() Baz() In short order, I allowed people to write the above as: LOOKAHEAD Foo() Bar() Baz() But this started me thinking…. I reasoned that there were doubtless plenty …