Lex,
"Lex Spoon" lex@cc.gatech.edu wrote:
[snip] Another starting point might be the refactoring- browser's parser. [snip]
Since the RB seems to be a useful thing to have anyway thats reasonable. But its no big deal, one can always remap the parse-trees to connect to RB. Give me/us a good reference for the RB-stuff. In particular where is the code for the parser you mentioned?
But anyway, what would people really like out of a parser? [snip]
- A clear parse-tree structure and symbol table. [snip]
- Ability to generate parse trees from code, not just Smalltalk code. [snip]
- Ability to execute statements straight out of a parse tree. [snip]
- Ability to make simple pattern-based modifications to a parse tree. [snip]
- Ability to clone a parse tree into a different format. [snip]
-Lex
The five commandments!
What do I want?
6. (Perhaps implicit in 5) Generate texts in diverse syntaxes, pretty printing, C-code generation, Python, PostScript, Jam, ..
7. Generate parse trees from diverse syntaxes.
8. Syntax-related editing. The RB and some of my own stuff, to be ported.
9. Graphical versions of programs (= interpretations of syntax trees)
10. Advanced highquality "pretty printing" like TeX
11. Easy connection to Morphic, a Morph is another tree. Compare (8) and (9)
12. Functional reduction semantics done on the parse tree direct. Compare (3) and (4)
13. A package of useful elegant general purpose tools for operating on trees. In particular Visitor-related things.
A parse tree should represent a program text with all details of linear representation abstracted, and no other information added.
However many want to put in more material like symbol tables, source code positions, comments, code generation details, reference to other parse-trees, ...
For me I want them to be completely without extra information and then make homomorphic maps (Visitors). Your 3..5 above fits into this.
However this gets me into trouble sometimes, so I have the following concrete proposal for parse trees:
1 Let each parse node have information that is of syntactic nature only.
2 but have en extension field as in Morph
This is a compromise:
- purists can live with a nil extension field that is never used. (In particular since sometimes it *is* used!)
- people who like to have information conveniently reachable from parse-nodes can live with the extra indirection (in particular since sometimes the information isn't entered)
This covers 1 .. 13 above.
Compare this with my other post today, "Morphic factoring". I think we have something here!
I have to go and will be away a few days. Have a nice weekend.
/Mats <ps> Thanks for all the feedback on block closures, I'll get back on this </ps>
Mats Nygren wrote:
"Lex Spoon" lex@cc.gatech.edu wrote:
[snip] Another starting point might be the refactoring- browser's parser. [snip]
Since the RB seems to be a useful thing to have anyway thats reasonable. But its no big deal, one can always remap the parse-trees to connect to RB. Give me/us a good reference for the RB-stuff. In particular where is the code for the parser you mentioned?
The current Refactoring Browser for Squeak is at http://www.bobjectsinc.com/squeakrbalpha/ .
This port looks pretty complete (including the parser), except for the UI. There are also links to the other relevant RB websites.
- Doug Way dway@mat.net, @riskmetrics.com RiskMetrics Group, Ann Arbor, MI http://www.riskmetrics.com
squeak-dev@lists.squeakfoundation.org