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 »
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 …
In my last post I reported that I had finally fixed the way syntactic lookahead works in JavaCC. This leads to the natural question: what about semantic lookahead? Well, what is historically called semantic lookahead in JavaCC is actually misnamed. It’s really just a bit of java code that is used to determine whether to enter an expansion or not. Something like: …
Fixed a Longstanding Bug Known Issue in JavaCC: Nested syntactic lookahead now works! There is a quite serious bug (let’s just call it by what it is, shall we?) of very long standing in JavaCC. Basically, syntactic lookaheads do not nest. This bug is documented in Theodore Norvell’s JavaCC FAQ, which by the way, is the best …
Bugfix! Nested syntactic lookahead now works correctly! Read More »
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 »
Some years back, I was traveling with a couple of Spanish friends, and this was late 2012. We were in Kunming, China and came across a poster that advertised some live music. I was fumbling around for a pen and a bit of paper to jot down the information. I thought to ask my traveling …
It’s Official! The Gigabyte is the new Megabyte! Hurrah! Read More »
A bit over a month ago, I wrote about my intention of tearing out support for “JAVACODE” productions. A JAVACODE production is really just a Java method that is like a pretend grammatical production. I could find very few JavaCC grammars in the wild that used this. I asked whether anybody would miss them and …