Lex,

"Lex Spoon" <lex at 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]
> 
> 	1. A clear parse-tree structure and symbol table.  [snip]
> 	2. Ability to generate parse trees from code, not just Smalltalk code. [snip]
> 	3. Ability to execute statements straight out of a parse tree.  [snip]
> 	4. Ability to make simple pattern-based modifications to a parse tree. [snip]
> 	5. 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>