[antlr-interest] 3.0 multiple language support

Tiller, Michael (M.M.) mtiller at ford.com
Wed Aug 4 10:29:35 PDT 2004


I want to clarify one thing.  In the current ANTLR, there already is a
special action language for building trees.  I don't have a problem with
that and I'm not suggesting that *it* be moved into a macro and put in
another file.  My point is this...it is fine to have an action language
that does all the *common* things (e.g. building trees, skipping tokens,
changing token types, etc).  But by externalizing everything that is
more complicated (looping over symbols in a symbol table, working with
specialized data structures, etc) you gain several things:

1) Language independence - The action language should have a clear
mapping to all target languages.  That mapping should include,
conceptually, the ability to do basic things like call functions/methods
in the target languages.

2) Improved readability - Sure you want the ability to put simple things
right there in the rules and you would degrade readability if you moved
those kinds of things.  But when you move more complicated stuff out of
the grammar, I think that is a good thing.

3) Not inventing another general-purpose programming language.

Based on the response to this thread, it seems like different people
would approach this kind of thing in different ways.  So it seems like
the best solution is to be as flexible as possible.  I think a basic
action language could be used to handle most grammar related actions.
For people who need to support multiple languages I think the macro
approach makes sense.  For those who still want language specific
actions in the grammar, I never objected to having that as well.

--
Mike

> -----Original Message-----
> From: Sebastian Kaliszewski [mailto:sk at z.pl]
> Sent: Wednesday, August 04, 2004 11:56 AM
> To: antlr-interest at yahoogroups.com
> Subject: Re: [antlr-interest] 3.0 multiple language support
> 
> 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
> 
> 
> 
> 



 
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/
 



More information about the antlr-interest mailing list