Re: ANNOUNCE: SableCC version 2.1

[Chris F Clark <cfc@world.std.com>]

Etienne:
> If you read the documentation on the SableCC web page, you will discover
> that SableCC will require an explicit name for elements that appear more
> than one in an alternative. See 1) for an example of explixit name.

Yes, good point.  I probably should have read your documentation
before offering any commentary.  (I can see from most of your
responses that you have addressed most of the issues I would have
thought pertinent.  For example, your naming and list returning match
what I (as a user) would expect given the other aspects of your tool.)

Commentary:
> > > Do not disallow getting children through indices (such as getChild(3)).
> > 
> > Yes, many users want to easily walk the tree ignoring its shape.
Etienne:
> The two default AST walkers implemented can visit all leaves by simply
> overriding the defaultCase() method. Additional AST walkers can be built
> to deal with all practical needs. I don't see, yet, the need to access
> children by number.
. . . [software engineering issues]

Yes, that would suffice.  I agree with your point that referencing by
number rather than by name is generally error prone and unnecessary
(once you can walk the entire tree by some convenient method).  Thus,
I think your software engineering arguments are valid.

Etienne:
> I am thinking of a partial support for resolving s/r conflicts. The idea
> is to limit the scope of validity of conflict resolution, so that the
> result is what you expect. If you want to specify the precedence for *
> and + in:
> exp = exp + exp | exp + exp
> the conflict resolution should have an effect only in this specific
> context, not all conflicts of * and +. (Think of * used somewhere else
> as a pointer operator. Should it really be considered to have the same
> precedence as the multiplication operator relatively to the addition
> operator)? I do not think so. Yacc S/R conflict resolution schemes don't
> take this into account.

I have thought about this issue also and am leaning toward something
of the form:
 exp = exp (+ %prec plus) exp
     | exp (* %prec star) exp 
However, the reasons for me prefering this (for Yacc++) is that Yacc++
has a tighter association with yacc and we already use %prec at the
end of an alternative means to override the precedence of the rule
like yacc does.  It is a logical extension to use parenthesized %prec
declarations to apply precedence to a specific token.

Another way of specifying conflict resolution appeared in a recent
(say last 2 years) TOPLAS article.  If I remember correctly, it was
coached in terms of which rule was to be preferred, which might work
well for you since you have names for every rule.  

Of course, you also have (the option of) names for almost every token,
and so you could also express conflict resolution in terms of those
names.  Something like the following would be quite explicit.  In the
example, I have capitalized the keywords of the conflict resolution
statements to make them obvious.  Also, I hope I'm recalling your
notation correctly and alternative names appear with a colon at the
beginning of the alternative they name.

 exp = plus_alternative: exp [plus]:+ exp 
     | star_alternative: exp [star]:* exp 

PREFER REDUCE plus_alternative OVER SHIFT plus
// makes a + b + c parse as (a + b) + c
PREFER SHIFT star OVER REDUCE plus_alternative
// makes a + b * c parse as a + (b * c)

Etienne:
> They key to hacking a SableCC generated compiler is customized
> Lexers/Parsers. These are classes derived from the generated
> Lexer/Parser classes. By overriding the filter() method, you can hack
> however you want. This method is called on every recognised token
> (lexer) and every reduction (parser). This gives you all (or at least
> most) of the flexibility you normally get by putting actions in the
> grammar. But this way, we keep the grammar "clean" of Java code.

This should suffice.  Of course, some grammars will only work with the
correct filters applied (e.g. C with its infamous typedef problem),
but that is a separate concern.  You seem to be very good at following
your maxim:
> SableCC is also different in its approach to compiler construction. It
> keeps, at all points, a very clear separation of generated/human written
> code. (It uses OO design patterns to achieve this.)

Hope this helps,
-Chris

*****************************************************************************
Chris Clark                    Internet   :  cfc@world.std.com
Compiler Resources, Inc.       CompuServe :  74252,1375
3 Proctor Street               voice      :  (508) 435-5016
Hopkinton, MA  01748  USA      fax        :  (508) 435-4847  (24 hours)
------------------------------------------------------------------------------
Web Site in Progress:          Web Site   :  http://world.std.com/~compres  
------------------------------------------------------------------------------