PetitJava work
Locked
 
|
Hi. I'm starting to need to parse Java code, and am going to be using the PetitJava as found on SmalltalkHub. In particular, I need access to the AST from this parsing.
So, I am going to be filling in the AST generation that is found there to cover more of the parsed syntax, following along the lines already laid out there.
A question I have, though, is why none of our AST models seems to print out the 'code' by default? This model, and I believe the RB Smalltalk AST, neither have a printOn: defined, so that when you inspect/explore the results, it is rather unpleasant to find out what the model is of. In some past models, I have included a default #printOn: to the model parts,so that when exploring the parsed results, it is easier to see which parts of the code you are looking at. (Most recently while delving into a 10,000+ line COBOL program). Personally, I find it much more enjoyable.
Is there a reason to not do this? I am already adding this to the PetitJava code as it makes it easier to see what I'm doing, but I can package it independently if anyone objects.
-Chris _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
On May 2, 2013, at 12:17 AM, Chris Cunningham <[hidden email]> wrote: > Hi. I'm starting to need to parse Java code, and am going to be using the PetitJava as found on SmalltalkHub. In particular, I need access to the AST from this parsing. > > So, I am going to be filling in the AST generation that is found there to cover more of the parsed syntax, following along the lines already laid out there. > > A question I have, though, is why none of our AST models seems to print out the 'code' by default? This model, and I believe the RB Smalltalk AST, neither have a printOn: defined, so that when you inspect/explore the results, it is rather unpleasant to find out what the model is of. In some past models, I have included a default #printOn: to the model parts,so that when exploring the parsed results, it is easier to see which parts of the code you are looking at. (Most recently while delving into a 10,000+ line COBOL program). Personally, I find it much more enjoyable. > > Is there a reason to not do this? I am already adding this to the PetitJava code as it makes it easier to see what I'm doing, but I can package it independently if anyone objects. I do not know. May be because we do not keep the formatting information. Stef > > -Chris > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by cbc
Hi,
Great. Let us know how it works. Concerning your printOn: question, you would like to do what you say in order to see the corresponding code inspecting the AST nodes, right? In this case, and especially if you are using the Moose image, you should simply extend the GTInspector with your dedicated presentation. For example, for the Smalltalk AST I already have such an extension. To see it: - execute: (Object>>#printOn:) parseTree explore - choose the second tab Cheers, Doru On May 2, 2013, at 12:17 AM, Chris Cunningham <[hidden email]> wrote: > Hi. I'm starting to need to parse Java code, and am going to be using the PetitJava as found on SmalltalkHub. In particular, I need access to the AST from this parsing. > > So, I am going to be filling in the AST generation that is found there to cover more of the parsed syntax, following along the lines already laid out there. > > A question I have, though, is why none of our AST models seems to print out the 'code' by default? This model, and I believe the RB Smalltalk AST, neither have a printOn: defined, so that when you inspect/explore the results, it is rather unpleasant to find out what the model is of. In some past models, I have included a default #printOn: to the model parts,so that when exploring the parsed results, it is easier to see which parts of the code you are looking at. (Most recently while delving into a 10,000+ line COBOL program). Personally, I find it much more enjoyable. > > Is there a reason to not do this? I am already adding this to the PetitJava code as it makes it easier to see what I'm doing, but I can package it independently if anyone objects. > > -Chris > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Reasonable is what we are accustomed with." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |