[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ANNOUNCE: SableCC version 2.1
Here are the answers to the questions that I have not addressed in the
>.. How does your AST definition or grammar differ from that of Demeter
>(the Northeastern project)? ...
>.. Have you read Steven Johnson's "Yacc meets C++" (1986) paper on
>these issues? How does your approach differ from his?
The answer to both 3) and 4) is SableCC ASTs are different in the visitor
pattern they implement. This extended version supports adding new types in
the visited data structure. (See http://www.sable.mcgill.ca/sablecc/paper.ps
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.)
>This point, was augmented by Nick:
>> (1) eliminating artifacts of operator precedence
>> (2) turning some constructs into proper lists/arrays
>> (3) various flattenings, like turning an IdentifierToken into a
>> String, or turning a modifier token (like "synchronized" in
>> Java) into a simple boolean field (isSynchronized)
>> (4) throwing away irrelevant information, especially tokens that act
>> as delimiters
>These are particularly good points. It would be interesting to see
>how each tool deals with each of the various flattenings Nick
OK. Let's answer this one (again).
SableCC supports all of these transformations. It does not so automatically,
but it gives you the means to do it simply. Here is how:
A) SableCC allows the inclusion of "ignored alternatives" in the grammar.
These alternatives are IGNORED by the parser generator. But, SableCC
generates classes for these "ignored alternatives". So the programmer can
use them later.
B) SableCC allows you to create "customized parsers" by simply inheriting
from the generated parser and overriding the filter() method. This allows
you to modify the AST at parse time. (You can also modify the AST after it
has been constructed. If memory is not a problem, then this approach is
C) SableCC's extended design pattern allows you to define your own "AST"
classes and add them to the generated AST classes. You can do this without
modifying any existing visitor or tree walker. You just write your new AST
classes and a new visitor/AST-walker that inherits from the generated one.
This allows you to handle point (3) above.
You can find an example of a customized parser in the document
http://www.sable.mcgill.ca/sablecc/thesis.ps . In this example, the
customized parser modifies the AST at construction time to eliminate
spurious tokens and simplify/modify the AST structure.
I hope this answers your questions.