Assertions, implemented in late 2021, are certainly an important feature in CongoCC — actually pretty much essential when writing grammars for very gnarly languages. However, as currently implemented, they are admittedly a somewhat strange hybrid construct. The main reason for this is that ASSERT has completely different semantics depending on whether you hit the assertion …
Revisiting Assertions, introducing the ENSURE keyword Read More »
(*Note that this article is largely superseded by the one here) JavaCC 21 now has assertions. There are actually two kinds of assertions: The assertion condition is expressed in Java code. The assertion condition is a lookahead expansion. The first kind of condition looks like this: ASSERT {someCondition()} Optionally, the assertion can have a message, …
I recently introduced a couple of "pseudo-annotations" (I’ll explain the pseudo part later) that can be used in code injections to express things in a much more succint manner. Here is an example: INJECT Foo : { @property String name; … } and the code generated in Foo.java corresponding to that line will be: private …
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 …
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 »
The FAIL construct is really pretty dead simple. Here is an example: A. ( “foo” | “bar” | FAIL “Was expecting \”foo\” or \”bar\” here!” ) At first I thought the above was just syntactic sugar, since you can, of course, already write: B. ( “foo” | “bar” | {throw new ParseException(“Was expecting \”foo\”or “\bar\” …
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 …
The overarching design goal of the JavaCC 21 project (dating back from when it was still called FreeCC) is to transform the legacy JavaCC tool into something more useful and useable. Having a clean syntax does not, in itself, further the first goal, but it is surely a key part of the latter. While it is possible for …
Reducing Visual Clutter: Introducing a New Streamlined Syntax for JavaCC 21 Read More »