> My suggestions came from the vision to be able to
> automatically compile arbitrary ST classes to speed
> up them if they are finished... Do you
> know the work of ST/X from Claus Gittinger?

We've invited Claus to OOPSLA this year and he has given a series of *very*
impressive demonstrations. It's a lot of fun to see people like Claus, Dan,
Elliot, and Ian in one and the same room (but be careful, their discussion
topics tend to give an uninitiated VM builder some decent headaches ;-)

> > It also gets confusing when "the same" construct works sometimes but
> > not others.
>
> This is absolutely true.
>
> Therefore I think most important - before further enhancements - are
> error messages from the compiler if it something cannot compile!

You're absolutely right - it's extremely annoying if the code generator
can't translate certain expressions correctly and one has to find out in the
C code. Any volunteers?!

> A short summary:
>
> There are two main developing lines:
>
> - To be able to compile as much existing - _not_ C'ish like -
> ST code as possible with as less changes as possible, and
> - to give the programmer maximal flexibility in writing C'ish ST with
> supporting as much C constructs as possible to gain maximal speed. I
> know that it is already possible with
> 	self cCode: 'some C code' inSmalltalk: [some ST code].
> , but this style isn't good for debugging purposes.

It's also bad for a number of other reasons - just extremely convenient in
some cases... I'd love to see most of this going away if there is a clear
way of doing it.

> P.S.: Here it is 20:41:42 now and I want to go out, so this is my last
> mail for a while...

Have fun!

  Andreas