SmaCC: First steps
Locked
12
12
 
|
Le 01/03/2015 09:13, kilon alios a écrit :
> > > I have this grammar definition in the python parser > > file_input: {{}} > | file_input <NEWLINE> {{}} > | file_input stmt 'statement' {{}} > ; > > So I would expect > a) the class to be name Pyfile_inputNode , instead is named > PyFileInputNode, why ? The naming scheme inside SmaCC removes the _ and capitalize the words :) > b) I would expect a "statement" instance variable in that class and > instead I get "statements" instance variable, why ? Because this two productions define a list of stmt (possibly empty) and the AST generation code notices that, so it adds an s to statement and prepare that instance variable to be an OrderedCollection. When I see the code doing that in SmaCC, I'm allways impressed. Ok, the theory behind is well known and not that complex, but the inference done (cascading through the grammar rules to fetch everything needed) is impressive (and basically fairly hard to master when you write a parser :(). Thierry |
|
|
In reply to this post by stepharo
Le 21/02/2015 17:36, stepharo a écrit :
> yes and I would love to see that documented in the chapter :) Need to make a part on pre-existing parsers in the SmaCC distribution: Smalltalk, C, Java, C#, Python. I've prepared two very limited examples for teaching purposes, illustrating: - symbol table creation and management: this is where some significant Smalltalk expertise is needed, and it hurts for students who haven't got any prior smalltalk knowledge. - if then else conditional evaluation with an AST and a visitor. Thierry |
|
"Because this two productions define a list of stmt (possibly empty) and the AST generation code notices that, so it adds an s to statement and prepare that instance variable to be an OrderedCollection." |
|
|
Hi Kilon,
Le 03/03/2015 13:33, kilon alios a écrit : > > "Because this two productions define a list of stmt (possibly empty) and > the AST generation code notices that, so it adds an s to statement and > prepare that instance variable to be an OrderedCollection." > > yes but I find it a bit misleading because even when there is a single > element it still going to create an OrderedCollection and still add "s" > to the name of the variable. It's because it is on a particular parse you have a single item; on another you may have two; etc... It becomes easier then to have an OrderedCollection containing one or more elements. The same code works. > By they way I have been successful into implementing , with your help, a > parser that parses python lists into pharo ordered collections. Python > tuples and dictionaries are next. Have not implemented nesting types but > that is very close too. > > Took me a lot of time to understand the syntax of SmaCC and moreover to > be able to understand the grammar used for the PythonParser2. I decided > not to change the grammar since it can do what I want as it is and > augment any additional parsing with my own classes. > > Now I understand the meaning of tests, PyAtomNode and more importantly > PyPowerNode. > > My overall experience with Smacc has been quite positive , the > documentation is in a good state though I would like more practical > examples especially on the matter of visitor. I love the Smacc syntax, > its compact , readable and fairly easy to understand. I really like the > design of the classes , make sense and are predictable. Which classes are you talking about? The node classes (PyAtomNode, PyPowerNode)? > A final question is how up to date in the configuration loaded with > configuration browser. I need to check that one. My approach for the moment is that whatever is done with SmaCC is at constant api, as much as possible. > The only thing I really missed from Smacc is a specialised to help me > browse the huge python grammar. Scrolling around became very tedious . Yes, I agree. A folding tree or something like that... In practice, what you see with grammars in source code is often next to horrible... very long files, happily mixing a long grammar to dozens or hundreds of lines implementing actions (the { }) for each rule in the grammar. Thierry |
|
|
"It's because it is on a particular parse you have a single item; on
another you may have two; etc... It becomes easier then to have an
OrderedCollection containing one or more elements. The same code works." yes I understand the intention. Now it clear and no longer confusing ;) "Which classes are you talking about? The node classes (PyAtomNode, PyPowerNode)?" Yes I was referring to node classes. I have to confess I have briefly looked at SmaCC classes cause it took quite a lot of time to understand the tutorial mainly because I wanted a deep understanding. "In practice, what you see with grammars in source code is often next to horrible... very long files, happily mixing a long grammar to dozens or hundreds of lines implementing actions (the { }) for each rule in the grammar." maybe it would be better to add the grammar of each node as class comment. This way it would be less necessary to look at the complete grammar. Not an ideal solution but it could help, at least it would in my case. I am also happy to report that I have made quite a lot of progress, I have been able to implement parsers for python lists and tuples, nested list and tuples taking numbers , floats and strings as values which are converted to OrderedCollections. Now I have started also parsing custom blender types like blender colors which are converted to pharo colors. Its fun because now I can use the new Pharo inspector to inspect Blender colors and the new inspector gives me a preview of the color too. Pharo is getting closer to Python and vice versa ;) |
|
|
also forgot to add that now I am using gitfiletree and it has been a very smooth ride. Works great with Ubuntu and Macos and I tested it across computers. Thank you for your hard work. On Tue, Mar 3, 2015 at 9:42 PM, kilon alios <[hidden email]> wrote:
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |