Yes, I think parameters and fluids are the same. I was wondering if
(with-redo-variables ...) could be a macro that expands to (with-fluids
...). Is that possible? It might not be.

Yeah, I had forgotten about the closure variables issue. That might turn
out to be a big problem with all of this, but we'll see.

Noah


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

> Relly kind of you to answer this quickly,
> good thoughts!
> On Tuesday, March 26, 2013 02:05:41 PM Noah Lavine wrote:
> > Hello,
> >
> > Two quick thoughts on this:
> >
> > 1. It's confusing to say "undo" and "redo", because those aren't in
> > the Scheme standard, and I don't know of any SRFIs that have them
> > either. Instead, maybe you could say "using continuations to
> > implement computations that restart". Or, "using continuations to
> > implement backtracking in a logic program" (if that's how guile-log
> > does it).
> Good point, I will define the wording.
>
>
> > 2. Can you say more about how you would implement them with parameters
> > and why that's not good enough? Maybe you could show equivalent code
> > snippets using parameters and your proposed form.
> parameters, and fluids are they not the basically the same? just a
> different interface? with parameters more flexible and fluids more
> optimized although parameters can be inlined many times?
>
>
> > 2a. If parameters work but are annoying to use, how about fluids?
> > Guile and a few other Schemes implement them. Maybe this could be a
> > justification for making fluids into a SRFI, instead of introducing a
> > new interface.
> I took them for basically the same concept. I just saw a srfi for
> parameters thought I should use them instead. I will try read the spec
> for fluids and parameters again.
>
> > 3. Points number 8 and 11 have no text at all, just code. It's not
> > clear what they mean.
> I will add text to this, good point.
>
> > 4. In general, I think this proposal is too low-level. You shouldn't
> > require people to implement it in a certain way; you just want to
> > convince them that it's *possible* to implement this reasonably.
>
> Please note that that in the semantics I mention for example integer
> numbers just to be precise. I do not expect people to use the code
> exactly as I write it. I do expect the implementors to optimize away
> quite a lot of what the spec describes e.g. I'm not describing a macro
> I'm describing an algorithm in for that case I believe to be pretty
> exact. The tail call properties is quite important for practiaclly be
> able to share logic programming using this srfi without it I fear that
> portability will only be on paper.
>
> > Overall, I think I would organize this into three sections:
> >
> >   I. Examples showing the need for a new type of variable.
> >   II. An exact specification of the semantics of these variables. I
> > gave a partial specification by rewriting special variables as
> > lexicals and using continuation-passing style in a previous email. I
> > think that would give the semantics that you want, and I can help
> > with that if you'd like. III. An example implementation. This doesn't
> > have to be the implementation that would really be used; it just
> > needs to be enough to show that it is possible to implement this in a
> > reasonable way.
>
> Good idea. btw I do have a implementation already that I can copy
> in. But not all logic can be coded without actually changing the
> compiler.
>
> Also I would add a discussion about optimisations to show that one
> would gain in speed and e.g. show that the argument for speed
> improvement is sound. Finally a discussion about ease of
> implementation could be good to show that we can get far by
> piggypacking on current technology and what things in the spec might
> cause the most trubble e.g. the dynamic condition that guarantees
> tail call property.
>
> I have an issue with continuation passing style and you point it out
> as well in your email. Special variables placed in a lambda would
> cause trouble with this approach and not only this I would like to try
> let the construct guard toplevel variables as well and hence these
> (horably) could change when someone reinstates a continuation. I do
> see the beuty of your approach and it describes and important
> optimisation that quite ofthen will apply, actually there is bloat
> using the guard and if you litter the code with guarding yoe relly
> want this type of behavior most of the time.
>
> Thanks
> Stefan
>
>