[antlr-interest] Language Independence

[Tiller, Michael (M.M.)]

> -----Original Message-----
> From: Terence Parr [mailto:parrt at jguru.com]
> Subject: Re: [antlr-interest] Language Independence


> > 2) In my lexer, I have a similar problem.  I need to 
> process comments 
> > and dump whitespace.  If I understand this correctly, this is 
> > typically done like this:
> >
> > WS
> >     : (' '
> >         | '\t'
> >         | '\n' { newline(); }
> >         | '\r')
> >         {
> > //            _ttype = antlr::Token::SKIP;
> >             _ttype = Token.SKIP;
> >         }
> >     ;
> 
> Actually $setType(Token.SKIP) is the "right" way ;)

Maybe I'm missing something, but I still end up with $setType(Token.SKIP) or $setType(antlr::Token::SKIP) depending on the target language right?

> > Once again, a slightly different syntax is required depending on 
> > whether this is C++ or Java (or C# or Python, etc).
> >
> > 3) This is the more significant (and in my opinion, 
> downright silly) 
> > obstacle to achieving language independence.  My grammar 
> file starts 
> > with:
> >
> > options {
> >     language = "Cpp";
> > }
> >
> > Why oh why am I prohibited from making this a command line 
> option?  I 
> > know this was discussed before, but I never understood the evil of 
> > command-line options.  Perhaps there is a reason why associated the 
> > language with the grammar would be useful (when the 
> grammar/treewalker 
> > includes actions for example).  But mine are (or could be made) 
> > essentially language neutral except for this one line!?!?!
> 
> If there are no actions then no problem: cmd-line would work.  Rarely 
> do you have no actions, however, and the {...} must be handled in a 
> language sensitive way :)

I should have been more specific here.  My goal is to have a lexer and parser that build an AST for all the target languages that ANTLR supports.  I realize that I need actions *at some point*, but I'd like to have a language neutral foundation on which a variety of tools could be built and I don't want to needlessly constrain the language that those tools should be built with.

> > How about a compromise.  Keep the "language = ..." option, 
> but allow 
> > the *default language* to be controlled from the command 
> line.  Then 
> > you do not lose or exchange this functionality, you merely augment 
> > it?!?  Can we agree to that?
> 
> What do you do about actions?

See above.

> > If these issues are resolved, I will be at peace with my ".g" files 
> > because I won't feel like I have needlessly 
> over-constrained their > use.
> 
> Perhaps just building trees is the answer...that is language 
> independent :)

Precisely.

> Ter

--
Mike

 

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