From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: redo-safe-variables and redo-safe-parameters Date: Wed, 27 Mar 2013 08:42:37 -0400 Message-ID: References: <13378334.Jv25yq6OaM@warperdoze> <1767639.rWRbQJn65G@warperdoze> <5150614.XCd6n4rqTv@warperdoze> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec53042e3afaf2304d8e7605a X-Trace: ger.gmane.org 1364388195 8713 80.91.229.3 (27 Mar 2013 12:43:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Mar 2013 12:43:15 +0000 (UTC) Cc: guile-devel To: Stefan Israelsson Tampe Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 27 13:43:40 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 1UKphR-0000nF-OB for guile-devel@m.gmane.org; Wed, 27 Mar 2013 13:43:29 +0100 Original-Received: from localhost ([::1]:55159 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKph3-00006U-Oh for guile-devel@m.gmane.org; Wed, 27 Mar 2013 08:43:05 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKpgz-00006E-8J for guile-devel@gnu.org; Wed, 27 Mar 2013 08:43:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKpgx-0001kP-5E for guile-devel@gnu.org; Wed, 27 Mar 2013 08:43:01 -0400 Original-Received: from mail-pa0-f52.google.com ([209.85.220.52]:49602) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKpgw-0001kF-SH for guile-devel@gnu.org; Wed, 27 Mar 2013 08:42:59 -0400 Original-Received: by mail-pa0-f52.google.com with SMTP id fb10so566039pad.39 for ; Wed, 27 Mar 2013 05:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=NrASR5rQeAjJg0w0pHBVORrNDijP4BD0XFL1GEjzAVM=; b=OEprIl8lNLL7B+F/c3837AMI889ccKca5e+bhsqwkBJwyDPha5RKQ4TzrMG/ScSpjH xxACl+oHlwJLultfdBJW65Y8a08ypJVJmHHqgFJS8dcJEz0ranmbR3zgjMNUO0HyG7NL 1RBYZaQin2wZxq7zhz8NVWeomp55MSay1qJKcs3wAQ10wk192bfRI6zQiblfoVb9brZf or1H+gMEu19+oel+YBa3hX6q9wNetNhFlvdmI8uKC12p8WZ8j8xlSNVQUDHyu5A+2Lv7 NPtzvMxn7hHltudQKvMLs46kdubxPLjyiuTXPawbc/4FxH/vU3hUD3bM/HauAP8H7jur TKOA== X-Received: by 10.68.1.231 with SMTP id 7mr28752307pbp.124.1364388178011; Wed, 27 Mar 2013 05:42:58 -0700 (PDT) Original-Received: by 10.68.157.42 with HTTP; Wed, 27 Mar 2013 05:42:37 -0700 (PDT) In-Reply-To: <5150614.XCd6n4rqTv@warperdoze> X-Google-Sender-Auth: h19gue5qbOted6ENG_yIW94C59k X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.220.52 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:16020 Archived-At: --bcaec53042e3afaf2304d8e7605a Content-Type: text/plain; charset=ISO-8859-1 Hello, Let me see if I understand the point of set! and set~. I think the goal is to have a variable that is redo-safe, except that if someone uses set~ on it, then it is not redo-safe. Is that right? If so, I think a variable like that is too hard to think about. I really don't think they should be in the language. If you want to make a redo-safe variable act like it's not redo-safe, you can use an explicit box. You do it like this: (redo-safe-variable ((a 1)) (set~ a (make-variable)) ...) Inside the ..., you don't set~ or set! a, you use variable-set!. That way, if you capture the dynamic state and restore it, it just resets to being the same box as it was before, which means that all of the dynamic states share the same variable object and the same value. I think this is what Guile would do for regular variables anyway - you just have to be explicit about it here. Note: this is actually a large part of the reason why I think redo-safe-variables (or fluid-let variables) are a good idea. I saw a quote from Sussman (one of the creators of Scheme) once that said that he should have made Scheme with immutable variables and explicit boxes for mutable locations. I think this is a reasonable extension of that idea. Best, Noah On Wed, Mar 27, 2013 at 3:13 AM, Stefan Israelsson Tampe < stefan.itampe@gmail.com> wrote: > On Tuesday, March 26, 2013 06:36:46 PM Noah Lavine wrote: > > Okay. I don't see a use for number 1. Could you explain why it's > > important? It seems easier to me to just let each variable have its > > own type. > Actually it has it's uses. > 1. > > Note. This ideom aims at being a sound extension to the case where we > have non boxed local variables that are never put into a closure and > where we mutate them with lexical-set directly. Maybe that is easier > to think of them this way. As you see this ideom will enable pretty > fast execution of the code in the common case where the variable is > never put in a closure. It will in the not uncommon case when you put > a local variable inside a closure and return it and preserve the redo > safe > property. > > I didn't see that fluid-let could allow this as well through an > optimization e.g. > > (let ((a 1)) code ...) > > redo safe and can be well optimized => > (let (a) > (fluid-let ((a 1)) code ...)) > > And it's actually better in many ways in that fluid-let guards the > outer context of the variable to be changed. On the other hand, > fluid-let does not mix well with delayed computations, my suggestion > does so indeed. So Different notions, different benefit. But as you > say thay are close to my number 2 suggestion > > > > As for 2, I believe that's how MIT Scheme's (fluid-let ...) works. I > > suspect that if you give up property 1, then fluid-let would do the > > job you want. > > No, parameter values are stored in different dynamic state and because > you have one dynamic state per thread usually (it's possible to let > threads share dynamic-state) the concpet is safe with respect to > multithreading. It does not look like fluid-let have that property. > > > a) > > Also, in the example you gave earlier (in your third email in this > > thread, beginning with "you need to combine fluids and dynamic wind > > ..."), I don't see the difference between set! and set~ semantics. > > b) > >It > > seems like the variables there have exactly the same semantics as > > fluids, except that you don't have to use (fluid-ref ...) to get > > their value. > > a) > set! means that you will box a value. The coders intention is that it > should > behave as such. With set~ you will many times be able to unbox the > value. But as you say, with the example it may look like they are the > same. But note that putting a set! in the code means that the > variables becomes unguarded and the with-undo-variables becomes a > no-op. Really The whole setup is done in order to keep ~ semantic > enclosed in a macro and the user of the macro should can work as if > the macro only uses local variables with no set!. > > b) > As I said, you are right that they are close in notion and many times > the semantic will overlap but as described above they are different. > > /Stefan > > --bcaec53042e3afaf2304d8e7605a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

Let me see if I understand the point of= set! and set~. I think the goal is to have a variable that is redo-safe, e= xcept that if someone uses set~ on it, then it is not redo-safe. Is that ri= ght?

If so, I think a variable like that is too hard to think about. I reall= y don't think they should be in the language.

If you = want to make a redo-safe variable act like it's not redo-safe, you can = use an explicit box. You do it like this:

(redo-safe-variable ((a 1)) (set~ a (make-variable)) ...)
Inside the ..., you don't set~ or set! a, you use variable-set!. T= hat way, if you capture the dynamic state and restore it, it just resets to= being the same box as it was before, which means that all of the dynamic s= tates share the same variable object and the same value. I think this is wh= at Guile would do for regular variables anyway - you just have to be explic= it about it here.

Note: this is actually a large part of the reason why I thin= k redo-safe-variables (or fluid-let variables) are a good idea. I saw a quo= te from Sussman (one of the creators of Scheme) once that said that he shou= ld have made Scheme with immutable variables and explicit boxes for mutable= locations. I think this is a reasonable extension of that
idea.

Best,
Noah


On Wed, Mar 27, 2013 at 3:13 AM, St= efan Israelsson Tampe <stefan.itampe@gmail.com> wrote:=
On Tuesday, March 26, 2013= 06:36:46 PM Noah Lavine wrote:
> Okay. I don't see a use for number 1. Could you explain why it'= ;s
> important? It seems easier to me to just let each variable have its > own type.
Actually it has it's uses.
1.

Note. This ideom aims at being a sound extension to the case where we
have non boxed local variables that are never put into a closure and
where we mutate them with lexical-set directly. Maybe that is easier
to think of them this way. As you see this ideom will enable pretty
fast execution of the code in the common case where the variable is
never put in a closure. It will in the not uncommon case when you put
a local variable inside a closure and return it and preserve the redo
safe
property.

I didn't see that fluid-let could allow this as well through an
optimization e.g.

(let ((a 1)) code ...)

redo safe and can be well optimized =3D>
(let (a)
=A0 (fluid-let ((a 1)) code ...))

And it's actually better in many ways in that fluid-let guards the
outer context of the variable to be changed. On the other hand,
fluid-let does not mix well with delayed computations, my suggestion
does so indeed. So Different notions, different benefit. But as you
say thay are close to my number 2 suggestion


> As for 2, I believe that's how MIT Scheme's (fluid-let ...) wo= rks. I
> suspect that if you give up property 1, then fluid-let would do the > job you want.

No, parameter values are stored in different dynamic state and becaus= e
you have one dynamic state per thread usually (it's possible to let
threads share dynamic-state) the concpet is safe with respect to
multithreading. It does not look like fluid-let have that property.


a)
> Also, in the example you gave earlier (in your third= email in this
> thread, beginning with "you need to combine fluids and dynamic wi= nd
> ..."), I don't see the difference between set! and set~ seman= tics.

b)
>It
> seems like the variables there have exactly the same semantics as
> fluids, except that you don't have to use (fluid-ref ...) to get > their value.

a)
set! means that you will box a value. The coders intention is that it
should
behave as such. With set~ you will many times be able to unbox the
value. But as you say, with the example it may look like they are the
same. But note that putting a set! in the code means that the
variables becomes unguarded and the with-undo-variables becomes a
no-op. Really The whole setup is done in order to keep ~ semantic
enclosed in a macro and the user of the macro should can work as if
the macro only uses local variables with no set!.

b)
As I said, you are right that they are close in notion and many times
the semantic will overlap but as described above they are different.

/Stefan


--bcaec53042e3afaf2304d8e7605a--