[antlr-interest] Lexer and Parser class packaging

[Jim Idle]

These can also be used to define variables/flags/etc that are specific
to the lexer and parser (and in fact cannot be seen by both at once).
However though I am not against it, this isn't my design, so you should
pursue such a change suggestion with Ter really. Though to be honest I
think by changing this you shift the issue of learning how it works
elsewhere: "My definition is turning up in both the lexer and parser and
I only want it in the parser?" 

IMO, it is just part of the learning curve for the tool and if it is
documented it should be enough, even if the syntax were ::l/h-ins at 4 ;-)
Writing recognizers, while not the most difficult thing in the world, is
also not for beginner level programmers. I do expect that if there is a
manual available that people trying to write recognizers would be at
least experienced enough in programming to consult it if they cannot
work something out by osmosis ;-). I don't think that ANTLR should be
written with ease of use as TOP priority, though it should not be
deliberately difficult to use of course.

In other output languages, there are potentially additional @ elements
that are language specific and the @ mechanism is meant to be fairly
generic. While java is the default output and the language in which it
is developed, I would bet that most serious applications would prefer
something other than the terrible overheads of calling JVMs when using a
recognizer, unless the rest of the system is already in Java.

Jim

-----Original Message-----
From: Martin Probst [mailto:mail at martin-probst.com] 
Sent: Monday, February 05, 2007 11:14 AM
To: Jim Idle
Cc: antlr-interest at antlr.org
Subject: Re: [antlr-interest] Lexer and Parser class packaging

Hi,

> Also, now that the book is virtually out the door, such things  
> should be
> much less of an issue providing the book is read beforehand.

Come on, you don't really believe people will start reading manuals,  
do you? :-)

> One possibility though is to not have a default for the @header {}  
> which
> will then just leave @lexer::header and @parser::header, which are
> probably more obvious.

The standard language is Java, and the standard use case for the  
header in that language is setting the package. The only other thing  
you can do there is add additional imports, which are probably  
identical for Parser and Lexer, too (or you just import all in both  
and don't care...).  I think the cases where people want different  
things for lexer/parser in the header are really corner cases. Stuff  
should work by default.

So I think this is indeed not a very user friendly design as the  
default of what the user wants and the default of what ANLTR does and  
requires do not really agree.

Regards,
Martin