Lex Spoon wrote:

> 1. A clear parse-tree structure and symbol table.  This was my primary
> motivation behind finally writing a custom parser for Lucid: Squeak's
> parser appears to be highly geared towards compilation, and it loves to
> use encoded integers that end up embedded in byte codes.

In my view, the biggest problem is that optimization is applied as part of
parsing, ie. you can't get a parse tree without having the transformations
of ifTrue:ifFalse:, to:do:, etc. applied to it. There should be a "pure
parsing" switch somewhere; it shouldn't be too hard to do, but I've been
able to circumvent this problem so far.

> (blocks and methods are very similar in the
> abstract, but they aren't in Squeak).

I've also thought about why MethodNode isn't a subclass of BlockNode--it
would make parse tree analysis simpler in many cases. Would it cause trouble
for some aspect of compilation that hasn't occurred to me? Or perhaps it
just didn't matter much for compilation as such--methods and blocks compile
rather differently, after all.

Mats Nygren wrote:

> The Parser will not inherit from Scanner but will refer to a Scanner.
> This adds flexibility which is sometimes good to have. And it is in
> accordance with my general view of how to handle syntax. I don't think
> it will run slower but I havn't measured it.

In general, I wouldn't worry about compiler speed too much/too early. Most
of the time is taken by reading from/writing to disk (I think it was about
60%)--this is true even for my partial evaluator. (Using the hack to
generate parse trees by decompiling bytecodes instead of parsing source from
disk gave me a ~500% speed increase in partial evaluation, at the only cost
of losing the comments.)