Re: Redo Safe Variables, New take

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

[-- Attachment #1: Type: text/plain, Size: 3172 bytes --]

Hi William and thanks for your mail!


On Thu, May 2, 2013 at 11:21 AM, William ML Leslie <
william.leslie.ttg@gmail.com> wrote:

> On 30 April 2013 06:15, Stefan Israelsson Tampe <stefan.itampe@gmail.com>
> 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

[-- Attachment #2: Type: text/html, Size: 4527 bytes --]