[antlr-interest] 3.0 final will require t.g has t in it

[Thomas Brandon]

The handling of both of these is a little illogical\annoying.
With the naming, if I set my grammar to MyLang say then I get
MyLang.java for the parser which isn't very good. So I change it to
MyLangParser but then I get MyLangParserLexer.java.
Perhaps if it automatically appended Parser to the parser name as
well. So "grammar MyLang" would generate MyLangParser.(java|tokens)
and MyLangLexer.(java|tokens). If this change was just applied to
combined specs it would produce natural output names but would
slightly complicate input-output mapping. MyLang.g could generate
either:
1) MyLang.java - a lexer, parser or tree parser
2) MyLangParser.java and MyLangLexer.g (currently this will produce
MyLang.java and MyLangLexer.java)
You could force the grammar name to include the type for seperate
specs, so a combined grammar would be MyLang.g while a seperate lexer
must be MyLangLexer.g. This makes input->output mapping consistent and
seems fine for parsers\lexers though AssignSymbolsTreeParser.g is a
little less natural than just AssignSymbols.g.

Also, perhaps the default scope could represent the combined grammar.
This seems more logical. In a combined definition the unscoped @header
block is naturally thought of as the header for both parser and lexer.
So you'd have:
@header { package mypackage; }
@parser::header { int parserState;}
@lexer::header { int lexerState; }

Tom.
On 7/9/06, Terence Parr <parrt at cs.usfca.edu> wrote:
>
> On Jul 7, 2006, at 7:14 PM, Micheal J wrote:
> >
> >>> On Jul 7, 2006, at 5:45 PM, Sohail Somani wrote:
> >>> Are we also going to require that *only* t exists in t.g?
> >>>
> >
> >> On Jul 8, 2006, at 02:06 AM, Terence Parr wrote:
> >> Yep.  One grammar per file.
> >>
> >> Ter
> a) it's "<grammarName>Lexer"
>
> b) Yup.
>
> @header {...}
> @lexer::header {...}
>
> Ter
>