[antlr-interest] grammar for jdk1.5 parameterized types

Ernest Pasour sasecp at wnt.sas.com
Fri Sep 19 07:30:50 PDT 2003

I found the Sun suggested grammar in the public draft for jsr014.  That was the "disgusting" grammar I referred to.  It looks to me like that might be the appropriate solution though.

I'm also going to take a look at the clover grammar, but it may be too much black magic for me.

Thanks to everyone for their suggestions.

-----Original Message-----
From: John P N Pybus [mailto:john-yahoo at pybus.org] 
Sent: Thursday, September 18, 2003 4:04 PM
To: antlr-interest at yahoogroups.com
Subject: Re: [antlr-interest] grammar for jdk1.5 parameterized types

I've had a quick look.  Jamie's solution uses a bracket counter in the 
lexer.  This is a global counter for the file and I'm not quite sure how 
it deals with odd comparison operations though:

if (n < 3) {
   new List<Map<String>>();

The clover grammer Matthew referenced at:


also uses a counter, but in the parser.  It gets rather complicated though.

What I remember is the Sun document Matthew mentions, which I also can't 
find.  It uses the aformentioned GT_GT and GT_EQ approach which does 
seem the simplest.



Terence Parr wrote:
> For some reason my last post didn't appear.
> See the C++ templates added to Java solution by Jamie Herre on the
> antlr site.  Not sure what he did any more.  However, it's a simple 
> matter in the lexer to track a tiny bit of context I think (i.e., did I 
> see "class" or a class name)?  It means the lexer needs access to the 
> symbol table.  I think Jamie did something clever, but can't remember.  
> Perhaps my audio lectures have the answer ;)
> Ter
> On Thursday, September 18, 2003, at 11:55 AM, John P N Pybus wrote:
>>mzukowski at yci.com wrote:
>>>You can't switch your lexer from the parser safely.  ANTLR doesn't
>>>work that
>>>way (infinite lookahead and all that).  I suggest getting rid of ">>" 
>>>as a
>>>token and making the parser look for '>' '>' as GT.
>>Hmm, with the lexer ignoring Whitespace wouldn't the parser then allow 
>>"n > > 3" as well as "n >> 3"?
>>I'd suggest using lookahead in the lexer to define 3 tokens GT_GT, 
>>GT_EQ, and GT corresponding to a '>' directly followed by another '>'; 
>>'>' followed by '=' and all other '>' chars, respectively.
>>You can use ( GT | GT_GT ) in your parser rules for generics, and can 
>>define the various shift operators as GT_GT GT; GT_GT GT_EQ EQ etc...
>>I haven't done this with the antlr java grammar myself, but I believe 
>>I've seen this approach used in other java1.5 recognisers (sorry no 
>>reference handy).
>>Hope this makes some sense.


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


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

More information about the antlr-interest mailing list