[antlr-interest] Keywords Vs Identifiers.

[Bharath S]

Hi Antlers,

I have some rules in my grammar, for time literals which require that 'TIME'
or "time" be appended to the front of the rule. For eg., time can
represented as TIME 99secs. The problem is, "TIME" is not a keyword and so I
cant have it in the parser. If I throw it in the lexer, it causes a clash
with IDENTIFIER rule, because the lexer sees the rule as

TIME: 'T' 'I' 'M' 'E' (Integer) ; and
IDENTIFIER: ('a'..'z'|'A'..'Z')+;

as expected. Is there a common workaround for this?

I can solve this problem by moving a whole bunch of rules in the parser back
to the lexer, just to make the TIME rule protected. But it doesnt make
sense, at all.

Any comments are most welcome.

Bharath.

----- Original Message ----- 
From: "Ric Klaren" <klaren at cs.utwente.nl>
To: <antlr-interest at yahoogroups.com>
Sent: Wednesday, May 19, 2004 10:05 AM
Subject: Re: [antlr-interest] Changing types and text in the parser ...


> On Wed, May 19, 2004 at 03:52:21PM +0100, Anthony Youngman wrote:
> > Simple little problem, just I don't know how to do it, and it doesn't
> > work like it does in the lexer ...
> >
> > gotost : (GOTO^ (INT { $setType( IDENT); } | IDENT) (COLON | {
> > $append(":"); } ) )
> > // if int, we want to change the type to ident. If no colon, then append
> > it to text.
> > ;
> >
> > GOTO can be followed by either an INT or an IDENT, and then an optional
> > colon. (And I think my grammar is slightly wrong here too ...)
> >
> > What I want to end up with is GOTO^ IDENT, where the text of IDENT has a
> > trailing colon.
> >
> > Actually, I've just realised I'm well off down the wrong track here, I
> > can just trap all of this in the treeparser, but (a) I would still like
> > to know how to do it, and (b) for Ter - the manual covers lexing and
> > parsing as being pretty much the same thing. I would have thought things
> > like this are a major difference that should be documented and I can't
> > find it in the lexing chapter...
>
> In the parser you should be able to do something like:
>
> parser_rule:
> t1:TOKEN1 { t1.setText("sometext"); t1.setType(MY_TYPE); }
> t2:TOKEN2 ;
>
> 'Problems' may of course arise if the tree is built before you change the
> attributes, which may lead to confusion... So you may have to patch the
> generated tree as well (or play a bit with the action code position and
> check the generated code to see if it does the right thing)
>
> Cheers,
>
> Ric
> --
> -----+++++*****************************************************+++++++++--
-----
>     ---- Ric Klaren ----- j.klaren at utwente.nl ----- +31 53 4893755  ----
> -----+++++*****************************************************+++++++++--
-----
>  Why don't we just invite them to dinner and massacre them all when
they're
>   drunk? You heard the man. There's seven hundred thousand of them. Ah? ..
>            So it'd have to be something simple with pasta, then.
>                  From: Interesting Times by Terry Pratchet
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
     antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/