> Smalltalk chooses a "fixed" point in language desing space that is good
> for 99+ % of the time.
> It also gives you all of the powerfull hooks to handle the remaining
> small amount.
> (The powerfull hooks are things like Behavior, #doesNotUnderstand:,
> #become:, thisContext, etc)
> These are very powerful for building frameworks that allow "ordinary"
> (99+%) methods to
> avail themselves of extreme coolness

That same argument could be applied to C++ by C++ers in saying that 99% of
the time you don't need classes exposed as first class objects.  For this
reason, and many others, I prefer Smalltalk.  However, I wish things like
message sending, message handling, instance variable accessors, and
messaging were more generalized and accessible.  I hope that eventually
Squeak will evolve far beyond ANSI Smalltalk.

> For example, Smalltalk give you single static inheritence, but if you
> want to implement
> multiple or dynamic inheritence, you can.

But not easily.

> Likewise for
> multi-polymorphism (although I'm
> sure we can do better than double-dispatching & coersion).  You can be a
> productive
> Smalltalk programmer, and never even know about primitive methods.

Of course, and that's a (or should be) key design goal.

> There was a good mind-bending paper at OOPSLA a decade or so ago, on how
> to add
> back-tracking to Smalltalk without VM support (using thisContext).
>
> I'm afraid that if we add stuff like this to Smalltalk, it will turn
> into CLOS.

In my opinion thisContext is a key concept and we should not strive to hide
it's presence.  Also, implementing a return with ^ seems non-smalltalky to
me.  It seems cleaner and more consistent to say "thisContext
terminateAndAnswer: someObject" (although it is obviously more cumbersome to
type).  The more expressive form clearly indicates exactly what is
happening.

And, InstructionStreams are really the fundamental unit of processing and
should take much of the responsibility currently held in Process.
Especially when considering how one would architect a Squeak that takes
advantage of multi-processor CPUs.

> I say we build stuff like this around the powerful hooks... much the way
> Exceptions
> are built around thisContext.  Smalltalk was never about quiet syntax.
> Smalltalk is
> about deeper semantics.
>
> 	self doStuff. ^
> 		vs.
> 	self doStuff. Processor terminateActive.
>
> I certainly don't want a quiet syntax for killing a process!  I want to
> HEAR the BANG
> of the bullet that kills it!

I didn't mean to imply that "thisContext terminate" should terminate the
Process (as it does), but rather that it should complete processing of a
method context (as "^self" does).

- Stephen