[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A lot of prduction classes



Hi Etienne.

Thanks for the quick answer, but I’m not sure if I explained my question 
clear enough.

You talk about Axxx classes and Pxxx classes. I suppose that you mean that 
the Axxx classes stand for alternatives and the Pxxx classes stand for 
productions. In the implementation the alternatives are all static final 
classes that extends a production class which always is an abstract class.

I do like the model with a Pxxx class used as a superclass for the Axxx 
classes that are alternatives for the same production. This can even be 
useful in combination with a reflective visitor, which possible could 
simplify maintenance even more.

But, the duplication that I was referring was the duplication of 
Axxx-classes for an alternative. Lets take an example to illustrate this:

goal = {a} a;
a = import identifier semicolon;

This Production will generate the following Axxx classes derived from the 
there Pxxx classes:
AA :: PA
AAGoal :: PGoal

And when we add a secondary alternative to goal:
goal = {a} a |
           {b} b;
a = import identifier semicolon;
b = import identifier dot star semicolon;

We will get two extra Axxx classes:
AA :: PA
AAGoal :: PGoal
AB :: PB
ABGoal :: PGoal

What I think is that it should be enough if the first grammar created one 
Axxx class:
AA :: PGoal

And that the extended grammar should add one extra class:
AB :: PGoal

I can’t see why this shouldn’t be sufficient. They can both be referred to 
as PGoal’s, they will always have get/set methods as the will always have an 
alternative/production or a Token as a child. It might be that there is a 
need to identify AA as both a PGoal and a PA, but that should be possible to 
implement by making PA an interface.

This would make the AST much smaller as there should be only half the amount 
of Axxx classes, which all has to be traversed / have non-static fields.

/Mattias

>From: "Etienne M. Gagnon" <egagnon@j-meg.com>
>To: sablecc-list <sablecc-list@sable.mcgill.ca>
>Subject: Re: A lot of prduction classes
>Date: Sun, 25 Feb 2001 14:36:27 -0500
>
>Hi Mattias.
>
>In the design of SableCC ASTs, one of the important goals was to
>simplify the maintenance of a compiler/interpreter over time.
>
>This motivation (and also "consistency") explains the generation of 2
>distinct classes for the production & alternative of productions with
>single alternatives.
>
>So, for instance, you can later decide to add a new alternative to a
>production without having to change existing code.
>
>To understand the problem more clearly: if we were to generate a single
>class, which one should it be?
>(a) Axxx, or
>(b) Pxxx
>
>If we choose (a), then if we later change the "single production", all
>other productions referring to this one through a child get/set method
>will have to change.  Any user code using these methods will also have
>to change the type of variables involved, e.g.:
>
>Axxx v = node.getXxx();
>
>=>
>
>Pxxx v = node.getXxx();
>
>If, instead we choose (b), then this means that some (but not all) Pxxx
>classes will now have get/set methods.  As soon as a new alternative is
>introduced on such production, the code performing get/set calls will
>have to change in a similar way to (a).
>
>Anyway, what is the problem with having more classes?  It certainly is
>not "instance size", as this is solely dependent on the number of
>non-static fields.  It is not either "method call" time overhead, as
>with a high probability, the get/set method will be encoded as "static
>call", as Axxx classes are final.
>
>The only problem left is class loading.  The time to load SableCC AST
>classes efficiently can be dramatically reduced by creating a .jar file
>and putting the whole application into it (specially if classes are
>loaded over a network, be it the Internet, or a network file system like
>NFS).
>
>Have fun!
>
>Etienne
>--
>----------------------------------------------------------------------
>Etienne M. Gagnon, M.Sc.                     e-mail: egagnon@j-meg.com
>Author of SableCC:                             http://www.sablecc.org/
>and SableVM:                                   http://www.sablevm.org/

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.