nygren at sics.se
Tue Sep 19 18:12:55 UTC 2000
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
More information about the Squeak-dev