yet more on processes

[ungar@thoreau (David Ungar)]

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