Hi,

I encountered this discussion in comp.lang.python. Quick question: is
stacklessness (modulo whatever reasonable qualifications you think are
appropriate) likely to be relevant to Ruby (say in the next 5-10 years)?

Courageous wrote:

> > > http://www.stackless.com/
> >
> > What exactly *are* these advantages? (Very curious...)
>
> Stacklessness allows certain specific optimizations for
> threading that wouldn't be possible otherwise. For example,
> it's quite possible to run 10,000 threads simultaneously
> in stackless Python, which is especially useful if you have
> lots of small simulation entities which are doing various
> and sundry routine and small tasks.
>
> One of the things that stacklessness enables is the "first
> class continuation" which is really a generalized primitive
> for doing flow control. If Python came coupled with any
> kind of metalinguistic/macro environment, it would be possible
> to any number of flow control and looping constructs,
> practically without limit.
>
> A "first class continuation" is a primitive with which
> the *programmer* can capture the current frame of execution
> and then return to that frame at a later state. If this
> doesn't make sense to you, take for example a simple
> function call in any language. Generally, executing a
> function call exists of some set of operations that
> include:
>
> 1. pushing some stuff onto the stack.
> 2. jumping to another region of memory.
> 3. manipulating the stack some more.
> 4. restoring the stack to its original state.
> 5. jumping to the original region of memory.
>
> (4&5 are sometimes swapped, depending)
>
> "first class" continuations expose the various pieces
> of functionality in 1-4 to the ordinary programmer. It
> is no longer a matter strictly controlled by the
> interpreter/compiler. The programmer can then make
> meta-level decisions that would have otherwise not been
> doable without the continuation construct.
>
> The idea of "stacklessness" per se is doing away with
> the push/pop operations altogether in order to facilitate
> the continuation itself. Without having to constantly
> push/pop stack elements, context switching between threads
> or regions of memory becomes very cheap.
>
> There's a cost involved here, but if you're doing lots
> of context switching, you very often don't care.
>
> This kind of environment is particularly of interest to high
> performance computiationalists who use massively parallel
> machines. In fact, there is a C-language-variant that
> implements just stacklessness just for the purpose on
> running on parallel machines and keeping context-switching
> overhead low.

--
Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)