Hello Red,
I do not see the benefits of avoiding an object representation of the syntax tree in favor of a flat SEXP representation.
I never said the s-exp representation was flat. It too is a tree.
What sort of code walkers do you mean? Can we just expose the macro-expanded Parenscript, rather than the `internal representation?'
I mean it is much easier to build recursive s-exp walkers than it is to build ones for a bunch of arbitrary CLOS objects, since in the latter case you have to know about their slots. If we want to build post-processing stages for ParenScript code, that will make it easier for us. The thing about the CLOS representation of ParenScript is that the different classes were really arbitrary, in the sense that inheritance could not capture the different slots they needed to have.
Optimization passes often require additional information about nodes of the syntax tree. With classes/structs, this information can be added as additional slots. Doesn't a transition from objects to SEXPs hinder the ability to attach information to nodes?
Actually it makes it easier, since now the format of the ParenScript intermediate representation is specified in two places (the special form definitions and the printer), whereas before it was specified explicitly once in the class definitions, and then twice in the special form definitions and the printer, implicitly by its usage. Since the printer interface now destructures the s-expressions with destructuring-bind (another big win for conciseness), adding additional information that the printer doesn't care about is as simple as declaring &allow-other-keys.
SLIME makes inspecting CLOS objects straightforward, and a print function can be defined to display syntax nodes in an informative fashion.
I don't think the SLIME inspector is any good for working with deeply-nested objects, which is what the ParenScript intermediate representation was. Yes, it's possible to define our own readers and printers for the CLOS representation, but given that it didn't provide any benefits (in reality, it bloated code size and introduced bugs, since inheritance allowed some operations to take place which didn't make sense), why bother?
SBCL uses structs as an internal representation and some developers would like more OO functionality:
I would really like to avoid making the ParenScript compiler as complicated and hairy as Python.
...a lot of things are done by mutating data structures which could be done much more cleanly by other methods...
...such as not mutating data structures, for which s-expressions happen to be an excellent fit. I really don't see any reason why the ParenScript compiler should be built in any way except for purely applicative (sans the macro definition state, of course).
I do not see much reason to avoid it for something like a syntax tree, which has an obvious class/object representation.
How about the fact that syntax trees have an even more obvious s-expression representation? Come on, we're programming in Lisp here! :)
For our (currently) very simple compiler, a SEXP representation is clearly sufficient to accomplish Parenscript's modest goals. Optimization and semantic analysis phases, my next concern, are free to build up a different representation from the primitive list format.
I would love to keep our compiler very simple and our formats very primitive.
Great. The decision to compile to statement/expression is best made earlier in compilation.
In particular, it's now up to the special forms themselves.
I'll check out these changes and see what I think. Ideally we should still be able to layer a package system on top of the simple symbol package to prefix mapping.
Can we keep these changes orthogonal to the compiler? Ideally, I would like the compiler to provide an interface that any namespace or code management systems would use in a modular way.
How are you planning to change the way printing is done? As far as I remember, DWIM-JOIN is one of the slower parts of the compiler, though I have not profiled in a while.
Ideally, I want to get rid of dwim-join and print directly to a stream instead of doing a ton of string consing.
Happy hacking, Vladimir
Happy hacking, Vladimir
Thanks, Red
[1] http://sbcl-internals.cliki.net/IR1 _______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel