[antlr-interest] 3.0 multiple language support

[Tiller, Michael (M.M.)]

> -----Original Message-----
> From: Sebastian Kaliszewski [mailto:sk at z.pl]
> Subject: Re: [antlr-interest] 3.0 multiple language support
> 
> Tiller, Michael (M.M.) wrote:
> >>>The problem of maintaining one grammar with language
> >>>dependent actions may be partly due to our inclination
> >>>to think of grammars as simple text files.  Imagine that
> >>>we used a text editor which could maintain multiple
> >>>versions of a file.  Such things exist for technical
> >>>documentation.  I remember reading that this was used
> >>>for airplane maintenance manuals so that common
> >>>features were updated for all airplanes, while
> >>>new models could have custom sections.  A printout
> >>>was customized according to the model selected.
> >>
> >>Yes, this is what we've considered for an IDE: use revision control
> >>not
> >>inheritance to change actions.  You are essentially forking a new
> >>branch.  Changes can be pushed forward with diff3 like behavior. :)
> >
> >
> > Is it April 1st already?  Geez, I guess it isn't.  Well in that case
I
> > have to assume you are serious so I'd like to cast a vote against
using
> > version control to handle language-independence.  Apart from the
fact
> > that inheritance and/or macros are a much better solution, consider
how
> > you would do *real version control* under such
circumstances...branches
> > on branches?!?  Yikes!
> >
> 
> How about allowing different language versions of the same action in
the
> same file? Something like:
> 
> my_prod
>    : my_subpod %C{ /* here C action comes */  }
>                %J{ /* here java action goes */ }
>                %P{ /* here python action goes */ }

Of the options I have seen so far, I prefer the one where the grammar
just has macros and the actions themselves are specified outside the
grammar, e.g.

some_rule
   : a:A "," b:B << process_some_rule(a,b); >>

And then you could weave together an action file with a grammar file.
So you might have a C++ action file:

void process_some_rule(A *a, B* b)
{
  /* Do something very general in this language */
}

With this approach, the only thing you need to formalize are the calling
conventions (how names and arguments map between the macro language and
the action language).  One nice consequence of this would be that, for a
given grammar, you could automatically generate the interface and/or
function prototypes for it (based on the content of the grammar and the
conventions).  Furthermore, what is nice about this approach is that the
macro language only needs to be able to express a few basic, common,
abstract things (function calls, argument passing, perhaps method
invocations, etc) and not be a whole new general purpose language.

It seems like this scales in many nice ways.  For example, the fact that
a macro is a semantic or syntactic predicate could be resolved pretty
easily from context and its return type could be inferred (Boolean?).  I
suspect there are many other examples of how these actions could be
treated as high-level, declarative information that could be analyzed
for consistency checking and/or to generate "wrapper" code.

--
Mike



 
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/