Re: redo-safe-variables and redo-safe-parameters

[Stefan Israelsson Tampe <stefan.itampe@gmail.com>]

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