Michael van der Gulik wrote:
> What is a fractal stack?

What I mean by that is, since full blocks may contain a reference to their
environment on the stack, as long as the block is around, that part of the
stack is around (including an ability to unwind it). This is different from
other languages like C or Java which do not allow blocks, so the stack is
always linear (though you may have a few in parallel, one for each thread).
Perhaps I should have used "tree like"?  Consider that each block in turn
might hold onto processes or other stack frames, and so on -- so in theory
it might even become a random network of references, so "Tree like" and
"Fractal" might both be wrong, since they imply hierarchy (though a
hierarchy of stack frames is typical in practice).

I've been wondering if I might just implement the Smalltalk threading stuff
on the JVM by using Java objects but by having a more Actor-ish approach
toward dispatching and interpreting Smalltalk code. Essentially,
"MessageContext" would become a first class object in a system without any
sense of a stack or stack frame (replacing "MethodContext", and doing
essentially the same thing but I think the name change worth making).
I'd actually prefer to just call it a "Message" but the parser uses that
class and it's a common term in Smalltalk. I'm not sure the "Context" part
is quite right either.

Presumably, every stack frame really just goes with a message sent to some
object with a selector and some arguments. So, why not just put any
information in the message instance as well (like a dictionary of temporary
variables)? Block evaluation would then also becomes constructing a
MessageContext instance. BlockContexts might merge with Messages perhaps?
Block evaluation might even imply just copying the message (assuming it was
stored in an instance variable and could be resent in theory, even just by
the debugger).

Essentially, there would not be a stack or a stack frame, just a web of
MessageContexts. Yes, performance is an issue, and I hear VW and other
commercial Smalltalks win big on speed by using regular stacks whenever they
can, but I like the elegance of a message-oriented implementation, and
taking seriously Alan Kay's suggestion that OO is more about message passing
than it is about objects (or somethings he said like that).
  http://gbracha.blogspot.com/2007/05/message-based-programming.html
  http://www.iam.unibe.ch/~denker/AlanKayOOP.html
>From the second link:
"The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak
is all about (and it's something that was never quite completed in our
Xerox PARC phase). The Japanese have a small word -- ma -- for "that which
is in between" -- perhaps the nearest English equivalent is "interstitial".
The key in making great and growable systems is much more to design how its
modules communicate rather than what their internal properties and
behaviors should be. Think of the internet -- to live, it (a) has to allow
many different kinds of ideas and realizations that are beyond any single
standard and (b) to allow varying degrees of safe interoperability between
these ideas.
If you focus on just messaging -- and realize that a good metasystem can
late bind the various 2nd level architectures used in objects -- then much
of the language-, UI-, and OS based discussions on this thread are really
quite moot. This was why I complained at the last OOPSLA that -- whereas at
PARC we changed Smalltalk constantly, treating it always as a work in
progress -- when ST hit the larger world, it was pretty much taken as
"something just to be learned", as though it were Pascal or Algol.
Smalltalk-80 never really was mutated into the next better versions of OOP.
Given the current low state of programming in general, I think this is a
real mistake."

And I can hope maybe the latest JVM's hotspot compiler might make up for
some of the slow speed of this approach by doing optimization behind the
scenes. And this approach might be more easily parallelized across multiple
processors perhaps? :-)

(Scala/JVM has an Actor library, by the way,but I am not sure it would help
much to use it).
  http://lamp.epfl.ch/~phaller/doc/ActorsTutorial.html

--Paul Fernhout