[parenscript-devel] Big compiler refactoring done.

[Vladimir Sedach]

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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>