Re: Redo Safe Variables, New take

[Stefan Israelsson Tampe]

Hi William and thanks for your mail!

On Thu, May 2, 2013 at 11:21 AM, William ML Leslie <address@hidden> wrote:

On 30 April 2013 06:15, Stefan Israelsson Tampe <address@hidden> wrote:
> Hi All,
>
> As I told you in an earlier mail I'm back cleaning up and reworking
> guile-log and
> refreshing the memory of the inner details of that code base enabled me to
> rewrite
> the spec for redo safe variables considerable. I think that it is much
> cleaner now and
> should be worthy of a good discussion.
>
> WDYT?

I had gotten the impression from your earlier emails that
redo-safe-variables was really about having a category of variable
that has its /binding/ captured as part of the continuation, rather
than have the environments captured; because each invocation of that
continuation shares those same environments and may mutate them.

 

The difficult things, as always, is probably to put into your head what goes on in mine

and vice versa,

Anyway

1. The idea to syntactically protect these variables was frowned upon by other so I tried

to remove those.

2. I was very explicit in the specification last time and went away from that and tried to talk

semantics. What I was after in my previously was the non lr guard I dont state this explicitly

now but tried to formulate a weaker form of condition of redo safeness for that guard

   (

     i) if no mutation in the thunk then it is a full guard

     ii) if there is mutation then it only guards it if there is

        non local exit passing the guard and no mutation in between

        before the reinstation of the state.

   )

With this weaker form the spec I stated previously would be a natural optimization. But

in a srfi specification we should try to not state optimizations. Anyhow I think that it is good for the 

understanding of the spec to discuss those optimizations and will add that to the doc.

 

This seemed like a simple, fairly orthogonal extension to the
language, but what you are proposing seems much more complicated.  It
may be useful to arbitrarily delimit what the continuation captures,
but even if that is a good idea I don't think I understand the API.
Later on it starts to sound like MVCC.

 I'm sorry but I'm a bit ignorant of MVCC. But the core idea is very simple, keep a list of variables you would like to

save and try to manage the list intelligently. I really think that it is a good idea to have this stronger form included 

as well because it will be needed to make logic programs easy to reason about. Actually my previous spec was not

standing on a stable ground because of not using the new complex way of modelling this.

Also note that in the reference I only uses the strong guard. E.g. it should be ok to use the strong version redo safeness 

for the weak guard. The spec only states (or should state) minimal requirements. E.g. redoing states with variables guarded variables in the weak sense have undefined behavior on variables where non of i) or ii) above is satisfied.

 

Have I misunderstood your motivation, or your implementation?

 

Maybe I'm not sure :-)

Happy Hacking!

/Stefan