[antlr-interest] Superclasses = best practise ...?

Jim Idle jimi at temporal-wave.com
Wed May 25 06:58:07 PDT 2011


For language separation, I do this:

1) Create the raw grammar with no actions;
2) Use perforce to integrate changes to language specific versions;

Because the actions in your target are going to be similar to:

{ myHelper.opAdd($e1, $e2); }

Transferring changes to the grammar is trivial.


Jim

> -----Original Message-----
> From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
> bounces at antlr.org] On Behalf Of Ranco Marcus
> Sent: Wednesday, May 25, 2011 1:04 AM
> To: antlr-interest at antlr.org
> Subject: Re: [antlr-interest] Superclasses = best practise ...?
>
> Hi Jim,
>
> Could you elaborate a bit on how you separate the logic from the
> grammar, especially when the grammar is supposed to target multiple
> languages?
>
> To my knowledge, the only way of calling the logic is by adding an
> action to a rule { ... } and use the target language to call a method
> (in superclass, delegate, etc.). Because the grammar then contains the
> method call in the targeted language, the grammar is still not 100%
> language agnostic.
>
> What if we could somehow define join points in the grammar and have a
> mechanism to hook those up to code in the target (much like AOP)? Do
> you know if any attempts in this direction have been made in the past?
>
> Best regards,
>
> Ranco Marcus
> Epirion Knowledge Solutions B.V.
>
>
> > -----Original Message-----
> > From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
> > bounces at antlr.org] On Behalf Of Jim Idle
> > Sent: Tuesday, May 24, 2011 6:42 PM
> > To: antlr-interest at antlr.org
> > Subject: Re: [antlr-interest] Superclasses = best practise ...?
> >
> > I uses super classes to separate the grammar from the code - you can
> > also use separate helper classes to do this too. I recommend keeping
> > the logic out of the grammar, but if you have a smaller grammar and
> > will never target other languages or want to reuse the grammar to do
> > more than one task on the language, then you are not required to
> follow the Maven archetype.
> > However, the lists of reasons not to put logic in with the grammar
> > soon piles up.
> >
> > Jim
> >
> > > -----Original Message-----
> > > From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
> > > bounces at antlr.org] On Behalf Of Hans-Juergen Rennau
> > > Sent: Tuesday, May 24, 2011 1:14 AM
> > > To: antlr-interest at antlr.org
> > > Subject: [antlr-interest] Superclasses = best practise ...?
> > >
> > > Hello People,
> > >
> > > this is a question about best practices when augmenting lexer and
> > > parser with Java code providing helper methods (or even inner
> > > classes for storare purposes).
> > >
> > > The Maven prototype "antlr3-maven-archetype" creates example
> > grammars
> > > which use super classes (AbstractTParser and AbstractTLexer). The
> > > comments in those super classes suggest to honour this as a general
> > > pattern: put helper methods in a grammar base class in order to
> keep
> > > the grammar light and clean. I think this has pros and a con. The
> > > con is that this way the compactness of "all-in-one-unit" is
> > > sacrificed; and reading the grammar one has to consult a second
> > > source. Also I noted that the Definitive Guide never made any
> > > suggestions to employ superclasses.
> > >
> > > So this is my question: would you recommend the superclass approach
> > > indeed as the best practise, or rather regard it as a good practise
> > > one might follow or not, perhaps depending on complexity?
> > >
> > > Thank you,
> > >
> > > cheers,
> > >
> > > -- Hans-Juergen Rennau
> > >
> > > List: http://www.antlr.org/mailman/listinfo/antlr-interest
> > > Unsubscribe:
> > > http://www.antlr.org/mailman/options/antlr-interest/your-
> > > email-address
> >
> > List: http://www.antlr.org/mailman/listinfo/antlr-interest
> > Unsubscribe: http://www.antlr.org/mailman/options/antlr-
> interest/your-
> > email-address
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-
> email-address


More information about the antlr-interest mailing list