RE: opinion on back end architecture

[Urdaneta, Alfonso E (N-Summitt Technologies)]

> -----Original Message-----
> From: Hans Aberg

> I program in C++, and I do not use Bison statement types, 
> because one must tweak it in order to get around the %union 
> limitation of not using C++ union with type having non-trivial
constructors.
> 
> Instead I use a polymorphic (virtual) hierarchy. Then every 
> statement type will be represented by a C++ class in that hierarchy.
> 
> In that setting, the lexer can either produce an object in 
> the polymorphic hierarchy, or a value outside it, which is 
> converted to a value n the polymorphic hierarchy explicitly by the
rule action.
> 
> So you can do both, which I do. In addition, I use a hybrid type:

Interesting.  This is more or less what I do.  

The language I am parsing has (among others) statement types like
"CALCULATE", "SETUP", "CONNECT", etc.  I have a class for each statement
type that handles building the internal representation of them.  

The problem I am running into is that there are primitives that are
reused by all statements, so what I ended up doing was having a bison
grammar for each statement type, and process the language in two passes.
the first one would pick out the general statement types, and then the
second one would call (for example) parse_calculate( "the statment in
question" ), whose parser would then call things Calculate::addVariable(
varname ), etc.

I'm fairly certain that I don't like this approach, but the problem is
that the language is not a true LALR, but rather a LR(N) (I think), and
once I put too many statements into the grammer, then things start
getting really ugly.  Breaking the language into multiple grammars makes
things simplyer, but then I end up with a lot of duplicate code.

Still haven't decided for sure which is the better tradeoff, but I
decided to go the duplicate code route because most programmers can
figure out duplicate code, but relatively few can debug complex bison
grammars, so the dudes that will maintain my stuff will more easily
figure it out the other way.

--
alfonso e. urdaneta