> One thing to "factor in" to any discussion of parsing in Smalltalk
> is the Refactoring Browser.  We reimplemented the Smalltalk parser
> and have it running in VisualWorks, VisualAge, and Squeak.  The RB
> is built upon a pattern matching engine that we use to analyze and
> modify Smalltalk code.  It is entirely syntax based, which means
> that it just matches abstract syntax trees.  It comes with a pretty
> good formatter, too.
> 
> The parser is not tied into a code generator.  This means that if
> it were to be used for the main parser, the optimization and code
> generation would have to be rewritten.  It would probably be a lot
> of work.  However, in the long run it doesn't make sense to have
> two parsers in the system, so they need to be unified, and we think
> that our abstract syntax system is cleaner than the others we've seen,
> and is just as fast.
> 
> -Ralph
> 

Definitely- whichever parser ends up in use, there should be one and only
one that is able to be used for a variety of purposes.  The path I am
taking with this right now is to first build another parser framework
to begin the formatting use case, and then over time modify that parser
framework into one that is useable for the other identifiable use cases,
such as code analysis or code generation.  The existing Squeak parser
would remain in place to handle code generation until that use case
works in the new framework.

The free parsers that I know of are: 1) Squeak's, 2) Little Smalltalk v.4,
3) Loki, and of course 4) The RefactoryBrowsers's .  Of these, I favor
evolving 1 or 4.  I am working with 1 as it is already in Squeak, but of
course the Refactory's parser is easy enough to bring over to Squeak.
The advantage of using 1 is that I can more readily identify which
parts of the code generation need to go where as I move from a
parsenode-based to a visitor-based code generation scheme.  That experience
would then be useful to me in using the BRParser (4) etc. as a basis
for a new Squeak parser framework.  Also, as I mentioned previously,
it gets me down into the guts of Squeak in places I'll need to understand
as I get on with my other Squeak projects.

Once the Squeak-visitors are built, I think it will actually be easy enough
for someone to use that as a guide to then build a Refactory-based set
of visitors to handle the same use cases.  At that point, we could
switch over to a Refactory-derivative parser framework as the sole Smalltalk
parser within Squeak.

For the sake of those who only want to use Squeak, the formatting use
case can be released fairly soon, and be left in place until we can
provide a solely Refactory-based solution.  Others wishing to participate
in the parser evolution could do so through e-mail, websites, etc,
and as I mentioned before I'd be happy to set up a website for this.

les