[squeak-dev] Re: Making a better Compiler for all

Klaus D. Witzel klaus.witzel at cobss.com
Mon Sep 1 16:13:38 UTC 2008


On Mon, 01 Sep 2008 15:09:31 +0200, Ralph Johnson wrote:

> On Mon, Sep 1, 2008 at 2:13 AM, Klaus D. Witzel wrote:
>
>> No, you cannot remove Squeak's compiler and use only NewCompiler, if  
>> that
>> would have been your question.
>
> That was not really my question.

NP, and sorry for disturbing your cycles.

> I thought that the purpose of the NewCompiler project was to replace
> the old compiler.  Am I wrong?

This would be interesting to find out, what "to replace" plans where  
there, also from a "managable" POV. I'm afraid I don't know any historical  
records which detail such plan, except the "can replace" wording mentioned  
in

-  
http://wiki.squeak.org/squeak/search?search=newcompiler&casesensitive=false&and=true

Anybody have more/other pointers?

> If so, is this just another way of telling people to support the
> NewCompiler project, or is it saying that we need a NewNewCompiler
> project.

No, I'm in favor of Igor's suggestion: make a new compiler. And ask people  
what they want in it, possible answers (but no limited to)

o faster compilation (faster than what? *)
o don't aim to be a framework for *everything*
o just be reliable and do the job
o decompilation from CompiledMethod guaranteed (!)
o very good syntax error messages/selections
o very good spelling/correction support
o no more "private" public hacks, because:
o extensibility/dialects only by subclassing (or so, Traits anybody?)
o better/more optimization of compiled methods?
o backward compatability at the bytecode level?
o evaluation restricted to what properly does #storeOn:?
o clear rules for name-spaceing and modularizing things?
o my favorite: less knowledge about how other classes work ;)

*) there are some 123 classes in NewCompiler & friends (not counting some  
roots like SmaCCParser) , versus some 30 classes in old compiler & friends.

> If not what is wrong with NewCompiler, and why can't it become the
> standard Squeak compiler some day?

Because too much packages depend on what/how old compiler makes/does  
things? (my POV depends on my use of things, YMMV).

For a prominent example, VMMaker cannot make much use of NewCompiler  
without rewriting the most vital parts of it almost from scratch (IMHO).  
But VMMaker is needed for getting the next VM out.

> If you are saying we should all get behind NewCompiler, then we can
> ask what needs to be done to finish it, but first I am asking whether
> that is what you mean.

I mean, that Squeak community cannot have both: complains about too many  
hacks being/"unmaintainable" in the old compiler and, be rather silent  
when NewCompiler happens to be mentioned.

That would be a huge waste of time and effort and a very dark & sticky &  
disgusting shadow over things IMHO.

The compiler is too important for letting business go as usual (e.g. let's  
wait what happens and if nothing happens then do nothing; no offense, we  
all have our full plate). That's how I think about it.

> I've hacked the Squeak compiler a little and I think that everybody
> who has done that will agree that it should be replaced.

Yes, replaced, made obsolete, so that nothing can depend on it any longer.  
Then it can be put on the downloadable package list, for people who want  
it and/or want to maintain it. Good move, that is.

> As far as I
> can see, the NewCompiler people have a good design, and it should be
> possible use it in place of the old compiler, if not now, then with a
> little more work.

Then why is it not used in a promising project like COG, right from the  
beginning? This rather rhetorical question has nothing against Eliot, I  
understand the answer he blogged.

/Klaus

> -Ralph
>
>





More information about the Squeak-dev mailing list