Dynamic scoping (was: Proposal: Squeak-E = Squeak x Kernel-E)

Avi Bryant avi at beta4.com
Mon Jan 27 23:40:59 UTC 2003


On Mon, 27 Jan 2003, Stephen Pair wrote:

> So remind me again why it's desirable to reuse the context stack for
> runtime environments (and ultimately exceptions for that matter)?  I'm
> starting to doubt that it is.  Yes, there are some things which are
> simplified...but I think I might be squeezing myself into a straight
> jacket because it happens to feel warm and cuddly.

I don't know about "runtime environments", because I don't know what your
goals are.  But dynamic scope should be implemented with the context stack
because that's how dynamic scope is defined.  One thing working with
continuations and other non-standard control flow techniques does is
force you to be clear about what kind of semantics you need for what.  I
have a definite use for a scoping mechanism wherein a binding's value is
resolved by looking up the execution stack.  Yes, this could be
implemented in some way other than looking through the sender chain, but
then you have to be careful that whenever somebody manipulates the stack,
you correspondingly adjust your bindings - and it's just too easy for this
to go out of sync.  If exceptions, for example, were implemented in some
way other than by walking the stack, I would have to muck about with the
exception system every time I invoked a Continuation...

Now, there are other times that I need other semantics, but for those
times I don't use dynamic scope.

> I'll have to read up an "amb"...but trippy should not be goal.  ;)

Amb was done for fun, and as a mind-bending demo of continuations.  I've
never actually used it, although I imagine it might be quite useful for
parsers and similar problems.  The simplest example is probably something
like:

|amb x y|
amb := Amb new.
x := amb oneOf: (1 to: 10).
y := amb oneOf: (1 to: 10).
amb assert: (x * y) = 42.
Transcript cr; show: {x. y}.

This will print

#(6 7)

to the Transcript.

> BTW, the fact that continuations re-use processes threw me for a loop at
> first.  When I was doing the stuff for Swiki.net, I didn't re-use
> processes, I just created new ones...it seemed a lot easier to follow
> the control flow.
>
> For example, when you evaluate a continuation, why not have the
> continuation happen in a separate process?

I think the implementation would be a lot more complicated, and I don't
see how it would be useful.  If you want the continuation to happen in a
separate process, just fork before you evaluate it.

> I've been thinking of ways to clean up Continuation a bit such that it
> eliminates such freakish behavior.  I think this might have the
> pleasurable side effect of making Seaside's use of continuations a bit
> easier to follow.

I doubt it ;).

Avi



More information about the Squeak-dev mailing list