While I completely agree with Urs and Peter, I also wanted to stick in my own 2 cent's worth.

Here's the way I look at it: Self does even less scheduling than Smalltalk in the VM. This costs you in more process switches, but may make it easier to play with the scheduler. Like Smalltalk, our standard libraries do not allow for concurrency. Unlike Smalltalk, you can easily change the fundamental system objects and just file them in, since our compiler/parser is "below the line". (Of course this makes it harder to change Self's parser.) I am very pleased by the minimalism in the Self VM's treatment of processes. I hope it works out.

By the way, on non-LIFO blocks: The whole issue of how far to reify activations and how much upward functionality to give blocks is a REAL toughie. The advantages are well known, but I think the costs are frequently underestimated. Specifically: performance. We would love Self to compete head-to-head with optimized C in runtime performance. I suspect that either reified activations or upward blocks would make this MUCH harder if not impossible. I do not believe that the work that the LISP community has done so far contradicts my view. For example, one LISP system that is considered pretty efficient (the subject of Kent Dybvig's SIGPLAN 90 paper on high-performance continuations) does not even use register windows on the SPARC--a MUST to compete with C on that machine. For regrettable, but good reasons, there is a dearth of head-to-head performance comparisons between C and LISP, and the ones we are aware of have used "shortcuts" like declarations or unsafe arithmetic functions. They do not give me any hope that, in the 1990's, we can approach optimized C performance AND do upward blocks in a language like Self. Sorry for the long answer, I hope to be proven wrong.

David