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 »
As the title says: as of this writing, the included grammars for Java and Python both support the latest versions of the respective languages, i.e. JDK 22 and Python 3.12. New Java Language Features Java language features that were not supported until quite recently were: Record patterns introduced as a stable feature in JDK 21. …
Announcement: CongoCC includes parsers for the latest Java and Python versions! Read More »
First of all, here is an instant gratification download link: freemarker3.jar. I guess that can be considered a preview version of a long-awaited FreeMarker 3.x release. For most typical usage, it is (at least for the moment) a drop-in replacement of older versions of FreeMarker. Actually, this is the same FreeMarker version that is contained …
The poster child for this feature would be something like the C-style multiline comment, i.e. /** * comment */ It is actually surprisingly difficult to specify this in legacy JavaCC (or JavaCC21/Congo up until very recently). One way is to break it into multiple regexp patterns using the MORE feature. Or, alternatively, there is actually …
Some days ago, I added a new setting. If, at the top of your grammar, you write: TERMINATING_STRING=”some string”; this means that the input you’re parsing is guaranteed to end with that string. If the file ends with that string already, then it does nothing. Otherwise, it tacks that string to the end. In actual …
The TERMINATING_STRING setting, a new (and quite minor!) feature Read More »
Now that the ability to generate fault-tolerant parsers is coming along so well, I have been thinking about what to do with the Java grammar included in CongoCC. I decided that the best thing to do was to do the incremental work to make it maximally correct. Ideally, it will serve as a reference implementation …
Moving Towards a Maximally Correct Reference Java Grammar Read More »
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 …
(N.B. Note added 13 June 2021: This article is useful in terms of understanding how to add token hooks to code. However, in terms of solving the specific problem outlined, the article is obsolete. See here for the updated solution.) Since I picked up my work on the JavaCC codebase at the end of 2019, …
“You can’t get there from here!” — The Problem of Context-Sensitive Tokenization Read More »
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\” …