more on non-LIFO blocks

[burdick@mentor.cc.purdue.edu]

The only time you have to do anything special with a block is when
someone assigns it to a non-temporary variable or returns it.  If they
don't do that, you can treat it as a just like you do now.  I guess a
non-LIFO block makes any regular blocks hanging around in its scope
(i.e. assigned to temporary variables somewhere) into non-LIFO blocks.

Couldn't you modify self's gnarly inlining to handle this?  I.e.
wouldn't inlining be able to track a lot of cases when it is known
that you don't assign a block to a non-temporary variable, return it,
or have it returned for you (like from one of your blocks)?  I think
that blocks which fit these constraints don't get passed around too
much, anyway, so they'd be easier to find.  This might at least work
for the standard control structures in self.

When a block is determined to be non-LIFO, you can just copy the scope
of the block.  Then, replace the variables in the stack frames with
forwarders to the newly created variables (it'd be a bit more complex
than that, because it gets hairier for cases of several non-LIFO
blocks sharing scope, but that's the general idea).  Alternatively,
you could use dynamic inheritance: kill the data slots in the active
methods up to (but not including) the top level environment and make
the active methods inheriting children of their corresponding copies.

Either of these would invalidate the code for the currently active
scope; you'd have to make a new map to change the variable references
into message passing (in the compiled code) for the temporary
variables in the methods.  *BUT* this only happens when you want to
use a non-LIFO block, and then it only affects the efficiency of the
currently active method/block objects, not the prototypes for them.


	-- Bill
	burdick@mentor.cc.purdue.edu