Please have a look at my closure compiler.  This puts bytecode generation
into a separate class (a subclass of Encoder).You can find the code on the
download page of my blog.

Marcus Denker and I are in agreement that we will merge my Closure compiler
into Markus' NewCompiler "some time soon".

The thought of a committee fills me with horror :)  I don't think we need
anything so baroque :)

Best
Eliot

On Mon, Sep 1, 2008 at 3:43 AM, Igor Stasenko <siguctua at gmail.com> wrote:

> 2008/9/1 Klaus D. Witzel <klaus.witzel at cobss.com>:
> > On Mon, 01 Sep 2008 03:59:44 +0200, Ralph Johnson wrote:
> >
> >> On Sun, Aug 31, 2008 at 10:19 AM, Igor Stasenko wrote:
> >>>
> >>> Hello folks,
> >>>
> >>> during my visit at ESUG i had a conversation with Stephane, about
> >>> different things, one of them is to make a better and cleaner compiler
> >>> implementation.
> >>
> >> I thought this was the purpose of the NewCompiler project.
> >
> > No, you cannot remove Squeak's compiler and use only NewCompiler, if that
> > would have been your question.
> >
> > /Klaus
> >
> >>  Is that
> >> project not good enough?  Or is this a request to make it standard?
> >>
>
> Yes, the main question about it, why it didn't replaced old compiler?
>
> There are some bad things in current compiler, which makes it really
> hard to play with:
> try implement a visitor pattern with its AST - you will go into
> trouble very soon, because some nodes properties is not fully exposed,
> or accessible in a cryptic way. That's why VMMaker, for instance,
> using an extensions/patching to be able to reach all interesting
> properties of parse nodes.
> A bytecode generation is spead among AST nodes, and interesting, that
> you can't insert some kind of analyzer or pre/postprocessor without
> patching methods, because there is no separation in responsibility who
> emits the bytecodes.A MethodNode returns you a hot baked
> CompiledMethod instance. It would be good to make a bytecode
> generation placed in separate class , which using a visitor pattern to
> generate a bytecode.
> There are also an agressive rewrite rules, sitting at early processing
> stage which replacing original selectors like #ifTrue:{ifFalse:} or
> #to:do: , so you can't see an original parsed AST from source code,
> but getting already twisted preoptimized tree , which not reflects an
> original source 1:1.
>
> >> -Ralph
> >>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080901/652c684a/attachment.htm