Doug Way wrote:

> Henrik Gedenryd posted some changes recently which improve the current parser
> somewhat, at least to separate the optimizing parse (for compiling) from
> non-optimizing (for pretty-printing, etc.).  (See
> http://groups.yahoo.com/group/squeak/message/36808)  I think we should try to
> include these in the next round of harvesting.
> 
> On the other hand, I'm not sure if those changes are a big enough step toward
> a really analysis-friendly parser or not.  I haven't done a lot of work with
> parsers.

I was able to write a partial evaluator into the current parse node classes
without having to make any invasive changes. PE is probably more complex
than most analysis tasks, so the parser isn't totally hopeless. I did
however also consider adding a parent reference to the parse nodes, so this
seems like a generally useful feature to have; I'd probably be in favor of
adding that if necessary.

You can get indices to the source code by using the decompiler, there is an
example somewhere in the Environments code.

I also recall there being some weirdness in the inheritance structure that
made some things less elegant than they could be.

There is a fair share of non-parsing code in the parse nodes, but that is
what you get with the limitations of inheritance. I saw Eric Gamma confess
in a talk (in relation to downsides with patterns) that Visitor wasn't such
a great idea after all. And it probably means something that parsers are a
favorite example used by the aspect people...

>> 
>> So I hope 2002 will be the year of Squeak. ...
> 
> Me too. :-)

Every year is the year of Squeak! The good thing about not being in fashion
is that you cannot go out of fashion.

My wish for the Squeak future is to see more work breaking new ground, and
less of "a Squeak version of X", or other variants of reproducing what
others have already done. But that is of course my personal point of view.

Henrik