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 17:15:22 +0100 Message-ID: <36877746.VlrjcRTRXD@warperdoze> References: <13378334.Jv25yq6OaM@warperdoze> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Trace: ger.gmane.org 1364400937 22620 80.91.229.3 (27 Mar 2013 16:15:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Mar 2013 16:15:37 +0000 (UTC) Cc: guile-devel To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 27 17:16:04 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 1UKt17-0006iT-Vv for guile-devel@m.gmane.org; Wed, 27 Mar 2013 17:16:02 +0100 Original-Received: from localhost ([::1]:35780 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKt0j-0002A6-Tb for guile-devel@m.gmane.org; Wed, 27 Mar 2013 12:15:37 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37545) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKt0c-00025x-8Z for guile-devel@gnu.org; Wed, 27 Mar 2013 12:15:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKt0a-0002nk-HK for guile-devel@gnu.org; Wed, 27 Mar 2013 12:15:30 -0400 Original-Received: from mail-la0-x22d.google.com ([2a00:1450:4010:c03::22d]:59867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKt0a-0002nb-9M for guile-devel@gnu.org; Wed, 27 Mar 2013 12:15:28 -0400 Original-Received: by mail-la0-f45.google.com with SMTP id er20so16127305lab.32 for ; Wed, 27 Mar 2013 09:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=vPQFRQEOcP0eDtkw/Mpb340FWe4szWRlqfnqfNAk6jk=; b=kW6nqyru6RQWVdyJ43zsPv4jziPJ24rckjAyUefDIw82W90nytw+dr2MZII4DtHXJq 2s9FbHoiH0RMNPJfrjO2piDWEX509DZiN2wsJJzVBFak/kmE2zpTXj9YmBgY6yIFEVNu 0rS05mc5emcGTAUT2pcjqwkp8TIeo2LTul278csOs9OwyN6s/0cbDOOgBjT5ki3ohSKD of9/SjVQgVQ7aMhm89+kG241qOvW6HVM6l6xVLh9s/FMDhCJeFK6ihTSxx6i90dnKjkE 1IUAlKlgPh/DKYUqBACFDJcM/XLQWWRTUqGGm/d2wOYXF72pah25BrGrc0W1Vw8MgFsZ UsQQ== X-Received: by 10.112.26.65 with SMTP id j1mr10227022lbg.90.1364400926898; Wed, 27 Mar 2013 09:15:26 -0700 (PDT) Original-Received: from warperdoze.localnet (1-1-1-39a.veo.vs.bostream.se. [82.182.254.46]) by mx.google.com with ESMTPS id i3sm8485685lbn.0.2013.03.27.09.15.24 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 09:15:25 -0700 (PDT) User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; x86_64; ; ) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22d 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:16027 Archived-At: On Wednesday, March 27, 2013 11:29:39 AM Noah Lavine wrote: > On Wed, Mar 27, 2013 at 11:04 AM, Stefan Israelsson Tampe < > > stefan.itampe@gmail.com> wrote: > > 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: > > 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. > > ... > > 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. > > Yes, I agree. What I'm saying is, there should be two different ways > to declare the variables, and once a variable is declared, you should > not need to look elsewhere in the code to see whether it acts like a > regular or redo-safe variable. If that is what you specified, I > apologize, but I thought that it wasn't. Hmm, your really are right in the sense that the common ideom in computer language design is to type a variable at the declaration of the variable. So basically a user would then do something like (for ((~ i) from 0) code ...) to force the intruduction of a redo safe variable. Hmm yolly good. This might be the better semantic and not trust so much on some magic. I would still require (set~ i 1) and (~ i) for these variables? With this approach you might want to consider to change with-redo-varibles e.g. (with-redo-variables (((~ a) 1)) code ...) to guard it in a redo safe manner and then (with-redo-variables ((a 1)) code ...) as a normal variable and beeing a noop. Error checking can be done via macros so now everything can be made ontop on a rich syntax system and r5rs. Does this sounds like as a better approach? > In particular, I think that having an MIT-Scheme-style fluid-let will > do the right thing here. I would be interested in talking about its > interaction with closure variables, but I think that it's the right > thing here with regard to continuations and mutable state. > > > 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. > > Yes, that's an interesting point. I think that I will rewrite the specification with the help of the assumption of the pressense of parameters srfi. I think that is smart. /Stefan