Context dependent enabled identifiers (reserved keywords)

[Cesare Zecca]

Gpl.jj defines a suitable token category

TOKEN : // Identifier
{
< IDENTIFIER: (<LETTER>|<UNDER_SCORE>) (<LETTER>|<DIGIT>|
<UNDER_SCORE>)* >
}

for identifiers.
Name() are identifiers being composed using a "name
separator" (currrently a '.' (dot) character)

void Name() :
{
}
{
<IDENTIFIER> ( <NAME_PART_SEPARATOR> <IDENTIFIER> )*
} // end Gpl.Name()

There is an identifier ("id") that is reserved and can be used to make
identifiers and names only for actual arguments of group functions.
There is a limited set of group functions (their names are known).

In other words we have that the grammar is integrally extended to the
"id" identifier only in the specific context of calls to group
functions.
Or, equivalently, "id" is a reserved identifier that cannot be used
but in the calls of group functions.

Any hint about how to handle such an issue?
Thanks in advance

ciao
Cesare

[Cesare Zecca]

On 5 Nov, 17:44, Cesare Zecca <Cesare.Zecca.p...@gmail.com> wrote:

> In other words we have that the grammar is integrally extended to the
> "id" identifier only in the specific context of calls to group
> functions.
> Or, equivalently, "id" is a reserved identifier that cannot be used
> but in the calls of group functions.

For the time being I have partially solved the problem:
The Function() productions have been split in two distinct
GroupFunction() and NonGroupFunction() production rules.
The syntax is the same fot all the GroupFunctions: thus it has been
possible to specify a suitable non-terminal for their argument list
that uses esplicitly the "id" token.

This does not solve reserved use of the "id" reserved word.
The InclusionExpressions

IdRef() <IN> Name()

(IdRef() is a Name that begins with the "id" reserved word, Names are
like <IDENTIFIER>( "." <IDENTIFIER>)*, can still be used as
UnaryExpression in any expression, i.e,

if ( id.imp in MySet; a + b ; a - b )

is successfully (and wronlgy!) accepted by the parser.

[Cesare Zecca]

I faced the problem using a number of different techniques and
following some tips found in the Theodore Norvell's JavaCC FAQ (http://
www.engr.mun.ca/~theo/JavaCC-FAQ/), as well.

1 - hand-handled grammar state
The Gpl grammar class singleton has been equipped with a state counter

private static
int
mInGf = 0;

The GroupFunction() non terminal recognizes (consumes) any
identifier for group function and increments the mInGf flag (switches
on the "in group function arg list" grammar state (IGF)). Such a
grammar state counter is decremented on leaving the GfArguments()
production that parses arguments for group functions.

2 - putting choices in the grammar
See also 4.19 How do I deal with keywords that aren't reserved?
(http://www.engr.mun.ca/~theo/JavaCC-FAQ/javacc-faq-
moz.htm#tth_sEc4.19)

Besides the <IDENTIFIER> token, I added to Gpl.jj grammar the
Identifier() non terminal that recognizes (consumes) <IDENTIFIER>s and
sometimes <ID>s, as well.
In detail: when it reaches an <ID> token, it consumes it when the
grammar is in the "in group function arg list" (IGF), otherwise throws
a ParseException to report the syntax error.

In the places where both an <IDENTIFIER> and an <ID> are equally valid
(depending on the grammar state), the <IDENTIFIER> token has been
replaced by calls to the Identifier() production.
In other places exclusive uses of either the <IDENTIFIER> or <ID>
tokens have been kept.

3 - group and non group functions
Two set of rules do correspond to group and non group functions. The
grammar is different for each type of function calls and thus the
syntactic rules are different, as well.
Both types of functions share basically the same prefix. Thus i had to
add two lookahead instructions to the PrimaryExpression

...
LOOKAHEAD( <GF_IDENTIFIER> <PAR_OPEN> )
GroupFunction()
|
LOOKAHEAD( Identifier() <PAR_OPEN> )
NonGroupFunction()
...

Pros
The lexical definitions continue to be all state-free
Choice has been centralized in the Identifier() production

Cons
I suppose that the the manual handling of the grammar state via the
mInGf singleton attribute can be be made better.
I have no idea yet (not yet a sufficient clear idea) that the manual
switching complies with handling of tokenization and parsing
exprections and is reliable. What does it happen to the mInGf when an
error is found while parsing the group function argument lists? How
and when the mInGf will be reset to the 0 initial value?
A quick code inspection simulating a wrong syntax seem to state that
mInGf is not deincremented: I should study how to catch expections in
the GroupFunction to reset to zero the mInGf flag.

ciao
Cesare