From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.devel Subject: Re: Redo Safe Variables, New take Date: Thu, 2 May 2013 17:15:40 +0200 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b6dcedc1c417604dbbdb519 X-Trace: ger.gmane.org 1367507811 25124 80.91.229.3 (2 May 2013 15:16:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 May 2013 15:16:51 +0000 (UTC) Cc: guile-devel To: William ML Leslie Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu May 02 17:16:50 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UXvFS-0007PK-1f for guile-devel@m.gmane.org; Thu, 02 May 2013 17:16:42 +0200 Original-Received: from localhost ([::1]:50697 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXvFR-0000I2-Jx for guile-devel@m.gmane.org; Thu, 02 May 2013 11:16:41 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50399) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXvEY-0007qy-0f for guile-devel@gnu.org; Thu, 02 May 2013 11:15:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UXvEU-0005l2-JD for guile-devel@gnu.org; Thu, 02 May 2013 11:15:45 -0400 Original-Received: from mail-pb0-x22b.google.com ([2607:f8b0:400e:c01::22b]:36663) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXvEU-0005js-93 for guile-devel@gnu.org; Thu, 02 May 2013 11:15:42 -0400 Original-Received: by mail-pb0-f43.google.com with SMTP id md12so400238pbc.2 for ; Thu, 02 May 2013 08:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mh7phyI7LFCy/8jLBrhYJ7+sJmbzjwPfjftx84FW+ig=; b=Jpux7oZFQ2VvZpSm3epum5ZM+fUd2nzOSOHtEma380RrgEADjHm/CjXl3kgIY1up/3 eZFdt8ivSAQy3ES5fzCOi6LVt5Zp77Tfo//WXeuRx/ORrI1bAPGLsqdkXGnZaziTvey4 AWRFgF/LuveaQbmmR0UrmBjMqUJeHOYLUfiRv25w0fhZKCs9MGXiSqzAxx74nAGs4Gk6 lTP4lE/8wKwvQCQQ/7x3jZ7PkzF6PQeyVJI7V/9I3JKMsx+wyFNAgBSyfMSSTsWDVYln sL20wNq7cRGBK44NN76DGlNECTIaiaggtEbdu9Q8r5VogS16RsXv1ivGf0d6vIYVJ1El FkcA== X-Received: by 10.66.144.69 with SMTP id sk5mr10577363pab.69.1367507740669; Thu, 02 May 2013 08:15:40 -0700 (PDT) Original-Received: by 10.70.22.5 with HTTP; Thu, 2 May 2013 08:15:40 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c01::22b X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16337 Archived-At: --047d7b6dcedc1c417604dbbdb519 Content-Type: text/plain; charset=ISO-8859-1 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 > 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 --047d7b6dcedc1c417604dbbdb519 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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, St= efan Israelsson Tampe <stefan= .itampe@gmail.com> wrote:
> Hi All,
>
> As I told you in an earlier mail I'm back cleaning up and reworkin= g
> guile-log and
> refreshing the memory of the inner details of that code base enabled m= e 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.
=A0
The difficult things, as always, is prob= ably to put into your head what goes on in mine
and vice ve= rsa,

Anyway
1. The idea to synta= ctically protect these variables was frowned upon by other so I tried
=
to remove those.

2. I was v= ery explicit in the specification last time and went away from that and tri= ed to talk
semantics. What I was after in my previously was the non lr guar= d I dont state this explicitly
now but tried to formulate a= weaker form of condition of redo safeness for that guard
=A0 =A0(
=A0 =A0 =A0i) if no mutation in the thunk then it = is a full guard
=A0 =A0 =A0ii) if there is mutation then it= only guards it if there is
=A0 =A0 =A0 =A0 non local exit = passing the guard and no mutation in between
=A0 =A0 =A0 =A0 before the reinstation of the state.
=A0 =A0)
With this weaker form the spec I stated previ= ously would be a natural optimization. But
in a srfi specif= ication we should try to not state optimizations. Anyhow I think that it is= good for the=A0
understanding of the spec to discuss those optimizations and wil= l add that to the doc.
=A0
This seemed like a simple, fairly orthogonal extension to the
language, but what you are proposing seems much more complicated. =A0It
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.

=A0I'm sorry but I'm a bit ignorant of MVCC. But the core ide= a 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=A0
as well be= cause it will be needed to make logic programs easy to reason about. Actual= ly 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=A0
for the weak guard. The spec only states (or should state) minim= al requirements. E.g. redoing states with variables guarded variables in th= e weak sense have undefined behavior on variables where non of i) or ii) ab= ove is satisfied.

=A0
Have I misunderstood your motivation, or your implementation?
=A0
Maybe I'm not sure :-)

=
Happy Hacking!

/Stefa= n
--047d7b6dcedc1c417604dbbdb519--