[antlr-interest] 3.0 multiple language support

[Sebastian Kaliszewski]

Thomas Dudziak wrote:
>>I really don't like this. Actions (esp. predicates) are part of the grammar. 
>>Separating them makes code much harder to read, analyse and maitain, as one 
>>has to jump around the code text.
>>Macros might be a nice idea, but they should be intermixable with the 
>>parser/lexer definition in the same file.
> 
> I find Michaels solution much easier to maintain. Imagine the Java 
> grammar with embedded actions for all supported languages - it will 
> surely be not readable anymore.

I'm not seeing that as unreadable. But spreading code doing particular 
(simple) thing among many places in different files is.
Besides it's easy to filter actions in all but particular language out (if 
syntax is clear, like: {c++: /* rule here */}). There could be even such 
action filter tool acompanying ANTLR distribution.


> Defining labels, e.g. 
> "process_some_rule" is far better IMO.

If someone needs to do some more complicated processing which is logically 
separate one should put that processing into additional function/procedure 
-- this is a prime good coding rule in all general purpose languages. But 
for simple stuff this makes no sense. Simple stuff should be done inline.
And from my experience most of the in-grammar actions are such simple stuff.

The separate actions proposition would for example enforce me to do 
something like that:

NEW_LINE
   : "\n" { process_new_line() }

And then in separate file:
process_new_line()
{
   my_line_count++;
   nextLine();
}


No, thanks... I vote strongly against such a nonsense.


> You can simply add all 
> information as parameters that is required by the action. The net result 
> is that the grammars themselves are target-language-independent 

And in what percentage of uses we need that?


> (remember the newbie asking about a Java version for the SQL grammar ?) 

That newbie still needs actions for the grammar. And it's easier to look at 
the code where (mostly simple one liners) actions are placed together with 
production rules, not in separate files. Like this is one of the advantages 
of most contemporary languages over C & C++ -- no stupid separatre headers 
to declare stuff which will be unrolled in another file.


> and you have the action in a concise form, perhaps in a single class. Or 
> Antlr generates abstract method declarations (for C++/C#/Java) in the 
> parser that the developer has to override in a concrete parser subclass 
> (template and hook).

Sorry, but one of the prime advantages of recursive descent parsing is that 
actions can be precisely placed, and together with generated code combined 
into whole methods.


> There are a few situations where this might seem like overkill

This is overkill in vast majority of situations not just few!


> (e.g. 
> maintaining and using a counter for a ()* subrule that shall be 
> traversed like 20 times), but there might be better ways to handle these 
> situations (e.g. defining syntax for it - say, ()[20] - and letting 
> Antlr work out the details).

And have yet another uncompheresible language loaded with [*&%(|\`@#@$ and 
stuff, i.e. "executable line noise". No, thanks...

rgds
-- 
Sebastian Kaliszewski



 
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/