ducasse wrote:
> 
> Lex Spoon wrote:
> > Stephen, I've pretty much decided that Squeak's parse nodes are best
> > left for *compiling*, not for analysis.  I had a rough time just
> > decoding what variable a variable referred to, for example.  This would
> > appear to be another example of the problem.
> >
> > It would be nice if Squeak had an analysis-friendly parser in it.  But
> > Smalltalk is such a simple language, everyone seems to just cobble
> > together a parser for their own needs.
> But the do it syndrome is something that I hate (when I arrived in Smalltalk
> people where telling me that I just have to do it if I need it and I hated
> that.)

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.

> For the moment I will try to continue with the current parser and stabilize
> Gutenberg but this is true that I will certainly look at the RBparser
> because I would like to have something that is documented (not patched
> several times) and that I can understand.

If the Refactoring Browser becomes a relatively standard tool for Squeak (maybe when the modules stuff happens), then the RBparser might become the de facto alternate parser.  (Of course anyone is free to roll their own parser, but it'd be good to have one well-supported analysis-friendly parser.)

> For me the definitive test for squeak will be after the modules and the
> start of the SqueakFoundation. ...
> 
> So I hope 2002 will be the year of Squeak. ...

Me too. :-)

- Doug Way
  dway at riskmetrics.com