Yes. So first of all build is red because of mondrian conflicts. Mondrian defines acceptVisitor: aVisitor in Object as "aVisitor visitNode: self". This way if during parsing something wasn't parsed into an AST node with defined acceptVisitor: method, or wasn't initialized properly e.i. something returns nil then we end up in the infinite loop. That's why job is red and not yellow.

Now the thing about the PetitJava. I see the parsed Java AST as wrapped expressions. This way type cast wraps expression that is casts into some type, negation expression wraps an expression that is negates. Chris sees it as properties for example accessor node has a property for cast and a flag for negation. Also in his vision a node should store an array of accessors if they follow each other whereas I say that there should be a couple of nodes wrapping each other. Also I think that code should be refactored as right now accessor node has negation flag with getters and setters, same is defined for method invocation. This functionality should be moved into a common superclass, same should be applied for type cast etc... Also it's a bit frustrating that one node can be created as a result of parsing several different grammar entities (you can read my full impression in previous PetitJava discussion).

It's fine that we have different views on the development as we can develop two different things. But if we want to have one project in Moose platform, other members of community should help to decide what we are developing.

Uko

Надіслано з iPhone

30 черв. 2013 о 15:43 Tudor Girba tudor@tudorgirba.com написав(ла):

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@me.com 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 tudor@tudorgirba.com написав(ла):

...

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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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

30 черв. 2013 о 19:27 Stephan Eggermont stephan@stack.nl написав(ла):

This also affects PetitDelphi, btw

Verstuurd vanaf mijn iPhone

Op 30 jun. 2013 om 16:24 heeft Yuriy Tymchuk yuriy.tymchuk@me.com het volgende geschreven:

...

Yes. So first of all build is red because of mondrian conflicts. Mondrian defines acceptVisitor: aVisitor in Object as "aVisitor visitNode: self". This way if during parsing something wasn't parsed into an AST node with defined acceptVisitor: method, or wasn't initialized properly e.i. something returns nil then we end up in the infinite loop. That's why job is red and not yellow.

Now the thing about the PetitJava. I see the parsed Java AST as wrapped expressions. This way type cast wraps expression that is casts into some type, negation expression wraps an expression that is negates. Chris sees it as properties for example accessor node has a property for cast and a flag for negation. Also in his vision a node should store an array of accessors if they follow each other whereas I say that there should be a couple of nodes wrapping each other. Also I think that code should be refactored as right now accessor node has negation flag with getters and setters, same is defined for method invocation. This functionality should be moved into a common superclass, same should be applied for type cast etc... Also it's a bit frustrating that one node can be created as a result of parsing several different grammar entities (you can read my full impression in previous PetitJava discussion).

It's fine that we have different views on the development as we can develop two different things. But if we want to have one project in Moose platform, other members of community should help to decide what we are developing.

Uko

Надіслано з iPhone

30 черв. 2013 о 15:43 Tudor Girba tudor@tudorgirba.com написав(ла):

...

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@me.com 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 tudor@tudorgirba.com написав(ла):

...

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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

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

---

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

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

Hi all,

From my work in the Delphi parser, and from my experience as java programmer, I will try to add some thoughts to the discussion.

First of all, I am still struggling to get the code for Delphi clean. I try to do this by sticking to some rules in converting the "standard petit parser result" to AST nodes. I follow the following rules: 1. when I have an "or" rule ( / or | ), I do not create an AST node. I only create an AST node for the sub rules. I.E. annotationTypeElementDeclaration gets no concrete AST node. I sometimes create a abstract AST Node with subclasses for the sub rules. 2. when I have a rule that has some syntax around the interesting part, I simple cut out the syntax. i.e. arguments. 3. when I have an list of things, I give back an array of the things. I.e. expressionList. Note that in the Delphi parser, we have some helper method to do this. For a complete list, see PPDelphiLexicon convenience category, and PPDelphiParser convenience category 4. For most other parse rules, I create an AST Node, that makes sense out of the tokens. This node is create with a onTokens: because I do not want too much interpretation in my grammar. And counting in an array is not very readable. The AST Node is always named after the rule in the grammar.

Secondly there are some semantic rules in Delphi I do not incorporate into my AST. For instance: in some cases an identifier is defined, and sometimes used. But in generating my AST, I do no attempt at all to make a difference between them. An identifier is simple a string that follows certain rules, and if it is a valid variable or constant or whatever, I do not care at that point. When I am generating FAMIX, I try to match names, so I can connect all things.

So this means I do not parse the Delphi the same way Delphi does, and do not intend to make an attempt to do so. Because my goal is not to generate code, but to generate an analysis model. A lot of rules I make are therefore more forgiving than a Delphi parser would be. I.E. A Delphi parser will generate an error when it encounters a call to an undeclared function. I will not do so. Also I want to include all variants of the various defines ({$IFDEF}).

Finally, I know java is pretty well defined with a good language spec. But when I would make a java parser, I will sometimes merge rules and/or break up rules, especially if I use petit parser. We did find some spec on Delphi that was fairly complete, that we took as base. But while parsing, we modified some of the rules, so it would make a better fit. I.E. we had several type of identifiers, we all cast back to identifier. So my advice would be not to make the language spec of java too holy, but to make the syntax and grammar rules as readable as possible, so it will be easy to match to the java spec.

Diego

Hi Doru,

I suspect part of the problem (with fast failing with petitjava is green) is that the petitjava ast parser test suite is incomplete. Very imcomplete. While this is 'bad', it isn't bad. The AST model is very incomplete at this point, and the choices are currently: 1- pick a target AST model, build the full test suite, and wait until someone gets around to building the AST model while petitjava stays red, or 2- choose an AST model that we agree on, and incrementally build the AST and tasts together. The problem with building the tests now for the AST model is that most of what is present is a lot of arrays of stuff - the raw output of the grammer parser - which isn't that desirable in my opinion - it freezes us with a partial AST model early.

-Chris

On Sun, Jun 30, 2013 at 5:43 AM, Tudor Girba tudor@tudorgirba.com wrote:

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@me.comwrote:

...

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 tudor@tudorgirba.com написав(ла):

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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev