Re: call-with-dynamic-root and fluids

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Maciej Stachowiak <mjs@eazel.com> writes:

> Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> 
> > 
> > So my suggestion is:
> > 
> > Remove `call-with-dynamic-root' from the Scheme interface, but keep it
> > in the C API.
> 
> Perhaps in some situations Scheme code also has good reasons to not
> let continuations jump into or out of a particular piece of code.

I accept this.  Let's keep it on both C and Scheme levels.

> > The current dynamic roots *have* their own wind chain.  What do you
> > mean by "walk up and down"?  What currently happens is that since
> > they have a dynwind chain of their own, call-with-dynamic-root
> > begins by winding itself out of the caller's dynamic context, in
> > order to be able to start a new chain.
> 
> This causes strange an unexpected behavior in some cases though. If
> you call-with-dynamic-root inside a dynamic-wind, your winders get
> unwound even though you haven't really left the dynamic-wind's dynamic
> extent.

The old concept was to create a root for a new dynamic context.  Then
I'd say first exiting the current dynamic context is a logical thing
to do, but this point is now outplayed.

> Dynamic roots should have a concept of being the child of
> another root perhaps. But then they aren't really dynamic roots.
> 
> I guess what users really want is not `call-with-dynamic-root', but
> `call-blocking-continuations' or something like that.

Yes (but I guess we can keep the name "call-with-dynamic-root").

But note then that the entire implementation of this mechanism becomes
restricted to creating a unique object representing the root, (this is
currently a number), and checking that caller and callee is associated
with the same object.

We don't need to think about children or wind chain or fluids or
anything else.

This way fluids, wind chain, and dynamic root become largely
orthogonal concepts, which is what they should be.  (I say "largely",
because the current wind chain value needs to have per-thread scope.)

> > I think we should make threads as light as we can.  If a computation
> > needs a new set of fluid values, it can surround itself with a
> > suitable fluid-let.
> 
> Is fluid-let in the classical Scheme/Lisp sense implementable on top
> of Guile's fluids?

I guess not.  I actually meant `with-fluids'.

I'm not quite sure what is the "classical" sense, but I guess it is

(define a 1)

(define (foo) a)

(fluid-let ((a 2)) (foo)) --> a

Guile's fluids have *mechanism* enough, but it's difficult to disguise
them as variables...