1 Jul
2013
1 Jul
'13
12:42 a.m.
For what it's worth: I agree with this wholeheartedly.
The reason for me is that (a looong time ago) there was a VisualWorks AT-Tools parser
specification for Java that did NOT follow the spec 100%. There were places where the
developers of the parse rules tried to 'outsmart' the spec and take some
'sensible' shortcuts to have a more compact parser/AST. One example (if I remember
correctly) was to skip the StatementExpression grammar rule.
To make a long story short, I used that parser in my PhD, and where they did not follow
the spec it was a *royal* *pain* to use the parser because I wanted to do things that were
slightly different from what the designers of the parse rules had in mind. If they would
have followed the language spec it would have been a piece of cake!
So, yes, stick to the language spec. Some PhD student will be glad for it at some later
time!
(Just my 2 eurocents … :-P )
On Jun 30, 2013, at 1:42 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote:
In my opinion in first place we should create tools
that work as close to a language specification as possible. Later we can make one more
subclass of a parser to generate different AST, or use Visitor to traverse an existing AST
to create a new one from it. I'm doing exactly the last mentioned thing to create FAST
model that is different from PetitJava AST, but when someone uses JavaParser he expects to
get something similar to what Java compile does.
Uko
Надіслано з iPhone
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD lab - Computer Science Department (DCC) - University of Chile