Re: fluid-let

[Russ McManus <mcmanr@eq.gs.com>]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Russell McManus <mcmanus@IDT.NET> writes:
> 
> > My attempt seems to work; give it a whirl and let me know if you
> > agree.
> 
> Your macro is fine for the usual case of single-entry/single-exit.
> But with the full power of continuations, it can actually happen that
> the flow of control enters your BODY (gives a nice chill down the
> back), leaves it temporarily, and then reenters it.
> 
> This would happen when you implement coroutines with continuations,
> say.  Each of the coroutines should be able to have their own
> fluid-let active and they should not interfere.

I guess that I need to work on my knowledge of continuations, in
addition to my knowledge of macros!

> Now, with your implementation, the fluid variables are correctly
> restored to the values that they have outside of the fluid-let, but
> when the flow of control returns, they are again set to the *initial*
> values specified in the flui-let form and not to the values they had
> inside the fluid-let when the flow of control left.  In addition, the
> external values are not saved when we reenter the fluid-let.  Thus,
> when we leave it a second time, the fluid variables are *again*
> restored to the values they had when entering the fluid-let for the
> first time.

I think I understand.

> When extending this to more than one variable, one should be careful
> to make fluid-let actually like `let', and not like `letrec', like
> your code does (by using `define').

Of course (sheepish grin).

> > The question I have is: how would one do this with
> > (make-fluid) instead of (gensym) so that this would work with threads?
> > Is it really basically just a couple of substitutions?
> 
> Rewriting this to use Guile's fluids would give you `with-fluids'.
> You still can't access the fluid objects like normal variables
> (because they are not normal variables).  In fact, when we have
> generalized variables on could simply write
> 
>     (fluid-let ((fluid the-current-module-fluid) my-module)
>       <do stuff with my-module being current>)
> 
> Having to use `(fluid-ref x)' instead of just `x' all over the place
> is inconvenient, but solving this is purely a syntax issue in my view.
> When we do solve it, by implementing symbol-macros for example, we
> should not restrict the solution to fluids.  The same thing (implicit
> setters/getters) is needed for variable traces.

Generalized variables.  Cool concept.

> [Doesn't syntax-case already have symbol-macros?]

I don't know much about macros.

Thank you so much for reading my code.  I don't know how I would learn
this stuff otherwise.

-russ


--
We're too busy mopping the floor to turn off the faucet.