User Tools

Site Tools


scan_statement

This is an old revision of the document!


The new SCAN Statement

JavaCC 21 introduces a new SCAN statement that is designed to supersede the legacy LOOKAHEAD. It is a key part of the newer streamlined syntax.

Note, however, that the older LOOKAHEAD syntax still works and will work for the foreseeable feature.

Here is a rundown of the differences between SCAN and the older LOOKAHEAD.

The parameters of SCAN (assuming there are any) are not enclosed in parentheses.

Thus, where you previously wrote:

LOOKAHEAD(3) Foo()

you would now write:

SCAN 3 Foo

Where you previously wrote things like:

LOOKAHEAD("foo" ("bar"|"baz")) FooBar()

you now write:

SCAN "foo" ("bar"|"baz") => FooBar

Note that the arrow is necessary in the above to separate the lookahead expansion from the expansion to be parsed. You can also write:

SCAN 3 => Foo

but the arrow is optional because it is not necessary to disambiguate anything.

The parameters of SCAN (assuming there are more than one) are not separated by a comma.

Thus, where you previously wrote:

LOOKAHEAD(Foo(), {someCondition()}) FooBar()

you now write:

SCAN {someCondition()} Foo => FooBar

(Note that the order was changed because in actual code, the semantic lookahead is actually evaluated first. At least in my implementation!)

Where you would previously write:

LOOKAHEAD(1, {someCondition}) Foo()

you now write:

SCAN 1 {someCondition} => Foo

A little point to note is that the new SCAN construct assumes indefinite scanahead by default. Thus, with the legacy LOOKAHEAD,

LOOKAHEAD({someCondition}) Foo()

is the equivalent of writing:

SCAN 0 {someCondition} => Foo

In the legacy lookahead, if you only have semantic lookahead, the number of tokens to be scanned is assumed to be zero, i.e. if the condition is true, you automatically go into the following expansion. JavaCC 21 makes the opposite assumption in these spots. Unless you specify otherwise, we assume unlimited lookahead.

The SCAN construct also allows the newer LOOKBEHIND construct.

Addendum: the SCAN-less SCAN?

Even the newer SCAN construct has some redundancies. There is no obvious reason to oblige anybody write even:

SCAN 3 Foobar

We could permit:

3 Foobar

It is trivial to allow this, but I have refrained for now, since I think there is a balance to be drawn between overly verbose constructs and the overly cryptic. I think that legacy JavaCC syntax, by and large, is overly verbose, and there has been a clear need to streamline it, but I don’t want to go too far. It is quite likely that I will go for an in-between option of allowing:

3 => Foobar

But again, that is not currently available. As of this writing, you can write:

SCAN 3 Foobar

or:

SCAN 3 => Foobar

In general, the possibility of making even the word SCAN optional is quite clear in some cases. What was previously written as:

LOOKAHEAD(Foo()) Foo()

can now be written as:

SCAN => Foo

or:

SCAN Foo

Again, it is quite feasible to allow simply:

=> Foo

In this case, because I think it is so common, we decided to allow this. And, in fact, you can see that this is already used in internal development, for example here.

===== The newer SCAN construct allows you to use the newer “lookbehind” construct

This is documented separately.

scan_statement.1601031754.txt.gz · Last modified: 2020/09/25 11:02 by revusky