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@gmail.com> wrote:
2008/9/1 Klaus D. Witzel <klaus.witzel@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.