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.ita...@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 > >
