[antlr-interest] a few questions
Ric Klaren
ric.klaren at gmail.com
Tue May 31 04:17:41 PDT 2005
On 5/31/05, Lloyd Dupont <lloyd at nova-mind.com> wrote:
> I have a big super grammar (the C grammar from ANTLR web site), which is
> uncorrectly implemented in some place
> So I thought of culling out unworking keyword (namely __attribute__ &
> __inline__)(as they don't bother me too much) with something like
>
> class ObjectiveCLexer extends GnuCLexer;
> ID:
> ("__attribute__") => SKIP_ATTRIBUTE { $setType(Token.SKIP); }
> | ( "__inline__") => "__inline__" { $setType(Token.SKIP); }
> | // classical ID code
> ;
(don't have much antlr docs/code handy atm, I might have misremembered
a thing or two)
This is probably a bit friendlier than the big lookahead option:
ID: // classical ID code
....
{
if( $getText.equals("__attribute__") || .. )
$setType(Token.SKIP);
}
;
If you have literal checking turned on for ID then you could also move
it into the testLiterals method by overriding that one.
> 2nd I have a problem with some unreservde keyword. something like that:
> typeQualifier
> : "const"
> | "volatile"
> // -- ObjectiveC addition --
> | protocolQualifier
> ;
>
> protocolQualifier
> : "in"
> | "out"
> | "inout"
> | "bycopy"
> | "byref"
> | "oneway"
> ;
>
> these protocolQualifiers are not reserved word! so they could be used as
> variable name, for example like that:
> struct MyStruct
> {
> int byref;
> int out;
> }
>
> and because they are not ID they break my parsing of MyStruct..... any
> ideas?
Hard to say what's best. You might want to deal with 'const' etc. as
if they were ID's in the parser and deal there with them being
reserved/non reserved keywords (or only with the protocolQualifier).
Probably at the expense of some ambiguity. There's some stuff in the
archives about id/keyword problems.
Cheers,
Ric
More information about the antlr-interest
mailing list