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 10:29:00 -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=f46d042f9f661deaec04d8e8dd54 X-Trace: ger.gmane.org 1364394594 14913 80.91.229.3 (27 Mar 2013 14:29:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Mar 2013 14:29:54 +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 15:30:19 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 1UKrMm-0005Uz-KZ for guile-devel@m.gmane.org; Wed, 27 Mar 2013 15:30:16 +0100 Original-Received: from localhost ([::1]:37213 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKrMO-0005wv-Kk for guile-devel@m.gmane.org; Wed, 27 Mar 2013 10:29:52 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57886) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKrLv-0005Rx-5w for guile-devel@gnu.org; Wed, 27 Mar 2013 10:29:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKrLt-00014t-Kx for guile-devel@gnu.org; Wed, 27 Mar 2013 10:29:23 -0400 Original-Received: from mail-pd0-f170.google.com ([209.85.192.170]:65506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKrLt-00014l-Bo for guile-devel@gnu.org; Wed, 27 Mar 2013 10:29:21 -0400 Original-Received: by mail-pd0-f170.google.com with SMTP id 4so3578626pdd.1 for ; Wed, 27 Mar 2013 07:29:20 -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=8V7If5yojS3UGX+S3Bvzrk4TjE5OsZrENpALsi07n1M=; b=MstC45BnD3QL5pOekAOWe7Vb97tN7fTuyXnXIk+Q767AEs6lqI1q3m6G1Mi6RI0w/0 w7Xor2HFxlKR7qSmrjrKNoD/g3WYugAqg+sAXifZuFTjXFRo2cJiNXZSUPoGX22e3Z8I Kx3+OUduLNos/zpUZvBUs/OpvAHLvqwqBAt32TgmPLcu1KvWIBQaA3qdP7TIEmZKN1GG lA20kAqSwTpWUKK/4AK8v9+6465Et9VbstbAKGlQACTtyno1nSPDCX7ppd7H8sbxw/y+ wwLGgzTycFbxDagnMkjP7SSYNe7yeklksMavRldjrJAHPNglDPPorjaHfZvOhZKPB6Kj 26qg== X-Received: by 10.66.72.3 with SMTP id z3mr27480220pau.125.1364394560578; Wed, 27 Mar 2013 07:29:20 -0700 (PDT) Original-Received: by 10.68.157.42 with HTTP; Wed, 27 Mar 2013 07:29:00 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: SDMsvrDFikPj0KYivrrM90bs240 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.192.170 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:16024 Archived-At: --f46d042f9f661deaec04d8e8dd54 Content-Type: text/plain; charset=ISO-8859-1 Hello, On Wed, Mar 27, 2013 at 9:22 AM, Stefan Israelsson Tampe < stefan.itampe@gmail.com> wrote: > On Wed, Mar 27, 2013 at 1:42 PM, Noah Lavine > wrote: > > 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? > > No that would be hard to reason about. set~ and (~ a) indicate that > you want to use it as a redo safe variable. set! and normal variable > reference and you will get normal behavior in user code. > I don't understand the difference. If I use ~, I get redo-safe behavior, and if I use !, I get regular behavior (value shared between dynamic states). Can I use ~ and ! on the same variable at different places in the code? If yes, doesn't it have to switch behavior? > > 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. > > Yeah that could be one thing to describe it, but I think that it's > much nicer to let the code behave as scheme when the user code it as > scheme as described above. > I see what you're saying, but I don't think introducing variables with new semantics and then hiding them is the right thing to do. After all, this new class of variables will also be "Scheme". Also, let's say you're writing a macro that introduces a redo-safe variable. You don't know whether the macro user will set it with set! or set~, so you have to write something that works in both cases. If you have two variables that you use together, it's much worse - what if the user calls set! on one of them but not the other? I think the only way to reason about programs is for each variable to have one type of behavior. Noah --f46d042f9f661deaec04d8e8dd54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,


On Wed, Mar 27, 2013 at 9:22 AM, Stefan Israelsson Tampe <stefan.itampe@gmail.com> wrote:
On Wed, Mar 27, 2013 at 1:= 42 PM, Noah Lavine <noah.b.la= vine@gmail.com> wrote:
> Hello,
>
> Let me see if I understand the point of set! and set~. I think the goa= l 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?

No that would be hard to reason about. set~ and (~ a) indicate that you want to use it as a redo safe variable. set! and normal variable
reference and you will get normal behavior in user code.

I don't understand the differ= ence. If I use ~, I get redo-safe behavior, and if I use !, I get regular b= ehavior (value shared between dynamic states). Can I use ~ and ! on the sam= e variable at different places in the code? If yes, doesn't it have to = switch behavior?
=A0
> If you want to make a redo-safe variable act like it's not redo-sa= fe, 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 bei= ng 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 Guil= e
> would do for regular variables anyway - you just have to be explicit a= bout
> it here.

Yeah that could be one thing to describe it, but I think that it'= s
much nicer to let the code behave as scheme when the user code it as
scheme as described above.
I see what you're saying, but I don't think introducing= variables with new semantics and then hiding them is the right thing to do= . After all, this new class of variables will also be "Scheme". A= lso, let's say you're writing a macro that introduces a redo-safe v= ariable. You don't know whether the macro user will set it with set! or= set~, so you have to write something that works in both cases. If you have= two variables that you use together, it's much worse - what if the use= r calls set! on one of them but not the other? I think the only way to reas= on about programs is for each variable to have one type of behavior.

Noah
--f46d042f9f661deaec04d8e8dd54--