On Mon, 27 Jan 2003, Stephen Pair wrote:

> What is not clear about those semantics?  Since the transcript output
> occurs before setting the value, the correct output is:
>
> 0
> 0

Well, unclear in that there's a conflict between what I think the correct
semantics should be (which we agree about), and the way in which it's
likely to be implemented ;).  In other words: take that example as a test
case, and make sure it passes; it will probably force you into
implementation strategies you wouldn't otherwise use.

> Originally, I wanted the ability set a value for all subsequent
> operations that occur in a process...however, to accomplish that *and*
> use the stack for maintaining scope enclosures would be quite convoluted
> (if at all possible).

I need the same thing, and yes, it's pretty near impossible (short of
inserting dummy contexts at the root of the stack).  For that kind of
state, I do keep a separate, Process-keyed tree, and the interface looks
like

 s := StateHolder new.
 s contents: 'foo'.
 [self assert: s contents isNil] fork.
 self assert: s contents = 'foo'.

I won't show it here, but the nice part is that you can cheaply snapshot
and restore the current value of all StateHolders in the Process at once -
which is necessary for web-browser backtracking.

It may be worthwhile to release Continuation, DynamicContext, and
StateHolder together as a kind of "obscure control flow" package (along
with my implementation of McCarthy's "amb", which is trippier than any of
them).  They're also the litmus test for Seaside portability - if you can
get all of their tests passing in a particular dialect, porting Seaside
will be a snap.

Avi