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@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