Refactoring Browser

Paul Baumann paulba at gemstone.com
Tue Sep 19 21:20:04 UTC 2000



> -----Original Message-----
> From: Mats Nygren [mailto:nygren at sics.se]
> Sent: Tuesday, September 19, 2000 11:13 AM
> To: hm.mosner at cityweb.de
> Subject: Re: Refactoring Browser
> 
> 
> Hans-Martin Mosner <hm.mosner at cityweb.de> wrote:
> > The RB parser is really a nice piece of work, especially since it is
> > embedded in a framework that supports code reflection and 
> manipulation.
> > To make good use of it in the Squeak environment, someone 
> (or sometwo)
> > would have to do the following:
> > 1. create a Squeak bytecode generator
> > 2. create a C code generator for Slang.
> > The second goal should be rather straightforward, as the C code
> > generator already has its own parse tree system. Merging 
> that with the
> > RB parse trees would be nice but not mandatory.
> > The first goal is somewhat more complicated: Currently, the 
> parse nodes
> > carry a lot of low-level information regarding the actual 
> bytecodes with
> > them. Burdening the RB parse nodes with all that 
> information seems not
> > the right way to attack the problem, but I don't see another simple
> > solution either.
> 
> I am already working on this, except that I have decided to first
> reorganize things (described in postings) and only then study 
> the RB in
> detail. I should have a reorganized code generator soon, and then a
> reorganized compiler, then more unification between the two and then
> connect it to RB. Comments?
>  
> As a preliminary way of getting things together I planned to do
> homomorphic mappings between the different types of parse trees.
> There was some discussion about parse trees on the list recently,
> I planned to take that up again when I have worked some more
> and hopefully we could get a consensus on how to do this that
> works for byte code generation, C code wrinting, RB, pretty printing,
> and whatever other things people use parse trees for. I 
> posted a concrete
> proposal for a compromise that would fit all purposes, other 
> possibilites
> are possible of course.
> 
> Possibly one should take TGen into consideration, I havn't 
> looked in detail
> into that yet either.
> 
> It will be very interesting to connect the RB to the 
> different syntaxes
> I'm working with.
> 
> How this relates to SqC's announced new debug/browse/script-machinery
> remains to be seen, in the best possible scenario this will be quite
> interesting.
> 
> /Mats


A "binary standard for code interchange" was an original goal for Camp
Smalltalk 1. The idea was to serialize a parse tree that could be loaded in
a dissimilar object space and traversed to generate native source. The
project was trimmed down to "binary standard for object interchange"--which
was focused on just on porting a serialization framework known as State
Replication Protocol (SRP). 

A Smalltalk parser for the purpose of *code* interchange is available under
the Mozilla license. The parser focused on generating portable and
lightweight nodes for transport. The code currently works on VisualAge and
VisualWorks. The nodes can be traversed to generate formatted Smalltalk and
Java code (Java source generation isn't complete). It should be easy to
generate bytecodes from the nodes. I image the idea could be expanded to
load an SRP encoded method parse-tree directly to a native compiled method.
You then have a dialect neutral (and perhaps language neutral) way to
exchange code--both multi-compiled and multi-source.

What is the best parser to use? The parser(s) are less important than having
standardized nodes. Many parsers could come into existence--perhaps one for
each language and customized parsers to support dialect specific syntax. The
nodes become the language of code [logic] exchange--and it is obviously best
to start with a single good node standard. 

The order I anticipate code-interchange happening is:

1) Binary object-interchange.
2) Standard parse tree nodes.
3) A generic Smalltalk parser.
4) A node visitation framework for generating source and bytecodes.
5) Port the parser and generator to multiple dialects.
6) A code repository file standard.
7) Advanced and specialty parsers.
8) Advanced source and bytecode generation.

Significant effort has already been put into 1 through 4. You can download
from http://www.effectnet.com/pbaumann/. The next step is to refactor the
parser and generator code to make it easily portable to other dialects (as
SRP already has been). I haven't done much to the parser and generator code
for a couple years. The code really needs to be adopted and evolved by
someone. Both Samuel Shuster and Rob Withers expressed interest in managing
the code. 

Paul Baumann
pbaumann at effectnet.com





More information about the Squeak-dev mailing list