Hi.

On Sun, Jun 30, 2013 at 3:42 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
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! 
The parser - yes, absolutely, 100% agree.  How Java compilers parse it is show we should part it. 

What is less clear to me is what the AST model should look like.  In PetitJava, we have a PPJavaSyntax that will parse the java file, ideally just like the compiler will.  It leave a bare parse tree in it wake.
We also have a PPJavaParser, which takes that raw parsing and builds an AST representation.  As was pointed out by Yuriy Tymchuk, I'd prefer a more compact representation of the parsed results instead of the more granular results.  Although either would work - it's just that for my purposes, the more compact makes it easier to get at the information that I want.  They should both be valid, though.

-Chris

(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


_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev