Okay. I don't see a use for number 1. Could you explain why it's important? It seems easier to me to just let each variable have its own type.

As for 2, I believe that's how MIT Scheme's (fluid-let ...) works. I suspect that if you give up property 1, then fluid-let would do the job you want.

Also, in the example you gave earlier (in your third email in this thread, beginning with "you need to combine fluids and dynamic wind ..."), I don't see the difference between set! and set~ semantics. It seems like the variables there have exactly the same semantics as fluids, except that you don't have to use (fluid-ref ...) to get their value.

Noah

On Tue, Mar 26, 2013 at 6:01 PM, Stefan Israelsson Tampe <stefan.itampe@gmail.com> wrote:

On Tuesday, March 26, 2013 05:38:03 PM Noah Lavine wrote:
> Okay. Let me see if I understand this correctly:
>
> Let's say, hypothetically, that there were variables that worked
> exactly like fluids except that you could reference them by simply
> writing their names, instead of using (fluid-ref ...). Would those be
> what you want?
>
> I was confusing our fluids and the (fluid-let ...) construct from MIT
> Scheme [0]. Are you looking for variables that behave the way
> fluid-let variables behave? (There's also a nice example on that page
> of how fluid-let works with continuations.)
>
> Best,
> Noah

for redo safe varibles no,

the logic for them is to,
1. Not bind a new value the value you see there is to be able to
dynamically choose to use plain old set! semantic or set~ semantic.

2. When the flow exits the dynamix extent through a non return
statement the current value is stored and when you jump back
it set's the redo-safe varible with to the stored value in case it has
been changed.

for redo safe parameters, they are exactly the same as parameters
except that if the dynamic extent is exited through a return statement
it will not do a full swap, it will just set back the parameter value
to the old state, not store the current state.

/Stefan