I missed that mail :). I could not keep up with what was happening with PetitJava during my holidays, but I certainly think it is a piece that people care about (at least from a user point of view). Your and Chris's efforts are certainly appreciated. In any case, I am not sure I understand why you think that PetitJava is really the problem given that the petitjava build is green. Could you elaborate? Cheers, Doru On Sun, Jun 30, 2013 at 12:41 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com>wrote;wrote: -- www.tudorgirba.com "Every thing has its own flow"

This also affects PetitDelphi, btw Verstuurd vanaf mijn iPhone Op 30 jun. 2013 om 16:24 heeft Yuriy Tymchuk <yuriy.tymchuk(a)me.com> het volgende geschreven:

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 &lt;yuriy.tymchuk(a)me.com&gt; wrote: ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

On Jul 1, 2013, at 12:19 PM, Chris Cunningham &lt;cunningham.cb(a)gmail.com&gt; wrote: My vote, if I would have had one as a PhD student that long ago, would be to have the bare parse tree, with a 1-to-1 correspondence with the specification. If there is a specification, of course. I'm not speaking about the case of Delphi, I have no experience with it whatsoever. I prefer no optimizations whatsoever because they come at the cost of less (or less straightforward) functionality. Of course this may not work for everybody (e.g. space & time issues when processing). So I understand the need for more compact representations. Yet one should be careful that the compact representation, if used a lot, will in the end become the 'standard' way of doing things, making the bare parse tree become the unpopular child of the family, with all the negative effects that this induces. That's all I'll comment about this subject for now, and leave you guys to actually do things. What I did that looong time ago was fun, but I have moved on to other things meanwhile, so I don't mean to drag this discussion on ;-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Hi On Sun, Jun 30, 2013 at 7:24 AM, Yuriy Tymchuk &lt;yuriy.tymchuk(a)me.com&gt; wrote: Thank you for writing this. It confirms to me that you do understand my position - mostly. I have attempted to remove the array of accessors from the AST nodes that I've added - these should be no nodes left like that (with an array of accessors or method invocations). Instead, each accessor or method invocation should have a 'receiver' that is is relative too, and it knows about nothing further up or down the chain. I don't think that the negation flag should be moved up the chain - from what I can tell (and I admit, unfortunately, that I am not a Java expert of any kind) is that the Java specifications do not consider variable accessors and method invocations as the same thing - rather, quite a bit different. hence the reason the negation flag was placed into two different trees by me. That said, you did a good job of summarizing where we differ on this topic. I agree with this, too. As Stephen guessed below, I have no opposition to the very detailed AST model. That said, I definitely don't have the personal drive to build it (that spec is huge!), and I'm sure my employer would not willingly pay for me to finish it, either. But, I would definitely like a more robust AST model - either where I have started, or where you or the community wants to go. Thanks, Chris Uko > > Надіслано з iPhone > > 30 черв. 2013 о 15:43 Tudor Girba &lt;tudor(a)tudorgirba.com&gt; написав(ла): > > I missed that mail :). I could not keep up with what was happening with > PetitJava during my holidays, but I certainly think it is a piece that > people care about (at least from a user point of view). Your and Chris's > efforts are certainly appreciated. > > In any case, I am not sure I understand why you think that PetitJava is > really the problem given that the petitjava build is green. Could you > elaborate? > > Cheers, > Doru > On Sun, Jun 30, 2013 at 12:41 PM, Yuriy Tymchuk &lt;yuriy.tymchuk(a)me.com&gt;wrote;wrote: > >> Yeah, I know, and I already told about it week ago when PetitJava was >> merged. Looks like no one cares about the emails that I send about >> PetitJava, but I want FAST to stay green and evolve. So most likely when I >> will return from the vacation tomorrow I'll make a fork and will depend on >> it. >> >> Uko >> >> Надіслано з iPhone >> >> 30 черв. 2013 о 12:11 Tudor Girba &lt;tudor(a)tudorgirba.com&gt; написав(ла): >> >> Hi, >> >> The FAST job is broken since a week: >> https://ci.inria.fr/moose/job/FAST-On-Moose/ >> >> Please take a look at the problems. >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> > -- > www.tudorgirba.com > > "Every thing has its own flow" > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev