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 and redo-safe-parameters Date: Wed, 27 Mar 2013 16:04:05 +0100 Message-ID: References: <13378334.Jv25yq6OaM@warperdoze> <1767639.rWRbQJn65G@warperdoze> <5150614.XCd6n4rqTv@warperdoze> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1364396655 4550 80.91.229.3 (27 Mar 2013 15:04:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Mar 2013 15:04:15 +0000 (UTC) Cc: guile-devel To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 27 16:04:42 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 1UKru3-0004KL-6a for guile-devel@m.gmane.org; Wed, 27 Mar 2013 16:04:39 +0100 Original-Received: from localhost ([::1]:58023 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKrtf-0004XP-6u for guile-devel@m.gmane.org; Wed, 27 Mar 2013 11:04:15 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKrtb-0004W9-GN for guile-devel@gnu.org; Wed, 27 Mar 2013 11:04:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKrtW-0007Vv-HU for guile-devel@gnu.org; Wed, 27 Mar 2013 11:04:11 -0400 Original-Received: from mail-da0-x22c.google.com ([2607:f8b0:400e:c00::22c]:44070) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKrtW-0007Vg-8P for guile-devel@gnu.org; Wed, 27 Mar 2013 11:04:06 -0400 Original-Received: by mail-da0-f44.google.com with SMTP id z20so4127451dae.17 for ; Wed, 27 Mar 2013 08:04:05 -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=Dse7eRuAMoYxgx8eKVd4LyXy0NiFZubyiL3NFqWEzCk=; b=GH1fmlF6vgMfzjkDqlBfQ9OnMKmTdmPvFx0d+DedFBSp/h948IWCFRHKK6j8no+2OA 3cEFqjGwQ6wxvLpvM30WXC6j5OvgKmr1Q2Dxrlt6k0e+ykzKyfxVInMZw4Ovz6NMPtVP +7TMkX3tAmWO7PoJkQW10S84wvxUPs/HoMo+WZXKbnzo5heLDRmEnZgAvudxqHnlpEu9 OXZcsH0fiRVXv1seeksXqCPSDkyS5UL7lEjFGup+GxjnR2Nfyha6j2RP6Ecte+IkrXaW aCcUbpFDqI+B+OqyBN8/qtijE/npjVI44Z7hYpNJaa5ZSyhmD1FeduZi7oYWEwSj0kNm sHFw== X-Received: by 10.68.4.97 with SMTP id j1mr29418319pbj.157.1364396645451; Wed, 27 Mar 2013 08:04:05 -0700 (PDT) Original-Received: by 10.70.45.8 with HTTP; Wed, 27 Mar 2013 08:04:05 -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:c00::22c 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:16025 Archived-At: Hi Noha, On Wed, Mar 27, 2013 at 3:29 PM, Noah Lavine wrote: > Hello, > > > On Wed, Mar 27, 2013 at 9:22 AM, Stefan Israelsson Tampe > 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? using set! means that you basically destroys the redo safe property. There is no sound concept where you mix them. If you want to mix them use ~ and add correct function guards to describe the semantics. >> >> > 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. You want to allow a user to let one variable behave as with set! and one as with set~. It is not broken, the useres sees ~ on one of the varibles and ! on the other. But a large part of the code base will be to use the ~ concept to achieve a funcitonality and then combine that into a functiton and macro that will behave as if there are no mutation beeing done at all, that is what the users sees. And things will be easy to reason about code. All effort is done to enable the macro writer wi actually hide the implementation detail of using set~ behind the scene, If we had a simple framework you would expose a boxed ~a variable if the user put it into a lambda and there woudl be suprises appearing. on the other hand it might be possible to express the semantic without doing it like I did. i do like th concept but specification can be buggy and clumsy put together. The process we are working on rioght now is in perfecting the idea. BTW. srfi's shouuld be careful about specifying dynamic state in order to achieve thread safe concpets, Scheme48 is threadsafe with their fluid-let, guile would not be. /Stefan