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: Tue, 26 Mar 2013 23:01:43 +0100 Message-ID: <1767639.rWRbQJn65G@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 1364335322 28258 80.91.229.3 (26 Mar 2013 22:02:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Mar 2013 22:02:02 +0000 (UTC) Cc: guile-devel To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Mar 26 23:02:26 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 1UKbwf-0006Au-7i for guile-devel@m.gmane.org; Tue, 26 Mar 2013 23:02:17 +0100 Original-Received: from localhost ([::1]:56368 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKbwH-0004VF-Bv for guile-devel@m.gmane.org; Tue, 26 Mar 2013 18:01:53 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35452) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKbwE-0004V9-2V for guile-devel@gnu.org; Tue, 26 Mar 2013 18:01:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKbwC-0003Al-Or for guile-devel@gnu.org; Tue, 26 Mar 2013 18:01:50 -0400 Original-Received: from mail-la0-x235.google.com ([2a00:1450:4010:c03::235]:34477) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKbwC-0003AY-GL for guile-devel@gnu.org; Tue, 26 Mar 2013 18:01:48 -0400 Original-Received: by mail-la0-f53.google.com with SMTP id fr10so14247537lab.26 for ; Tue, 26 Mar 2013 15:01:47 -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=Ov5/MM24Xgnuq8rxl4ZvjJ8SP5ykO1rV8stOhRLxBhc=; b=nR69Yj0aJdCsiF5hw2T6tyVYsTX0v3VuwOju9ncDMRvHacYtqEnR4U0fZKjc8hKlfL BV2xYsLGoEmIVtTjoveQKTRpHZY3J4D7DWKvv48Am6q9MJ23kNrwYxmSgM7RxNPeYQa4 fPKBjHRAg/sElgaO76xOK4wR9amy2lFbmvH/46VqVyyWEKCPVGR5+F6I6iDKdT0K6gyM byWVu1lEjE8IEgdFIqR14lZVXV/0EDiCQLUuI7XKC6+iQuRNeHDinFMJ293bMAQGdQwC 0lpMHo4sBHEJQ/oYkT5qC+RZPC5+7+4a23izzHb6uKsXB6cj0NN0V1Ww1g7/9J8l/a7/ OAmA== X-Received: by 10.112.36.2 with SMTP id m2mr8930504lbj.100.1364335307373; Tue, 26 Mar 2013 15:01:47 -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 e9sm7319829lbz.1.2013.03.26.15.01.45 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Mar 2013 15:01:46 -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::235 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:16009 Archived-At: On Tuesday, March 26, 2013 05:38:03 PM Noah Lavine wrote: > Okay. Let me see if I understand this correctly: > > Let's say, hypothetically, that there were variables that worked > exactly like fluids except that you could reference them by simply > writing their names, instead of using (fluid-ref ...). Would those be > what you want? > > I was confusing our fluids and the (fluid-let ...) construct from MIT > Scheme [0]. Are you looking for variables that behave the way > fluid-let variables behave? (There's also a nice example on that page > of how fluid-let works with continuations.) > > Best, > Noah for redo safe varibles no, the logic for them is to, 1. Not bind a new value the value you see there is to be able to dynamically choose to use plain old set! semantic or set~ semantic. 2. When the flow exits the dynamix extent through a non return statement the current value is stored and when you jump back it set's the redo-safe varible with to the stored value in case it has been changed. for redo safe parameters, they are exactly the same as parameters except that if the dynamic extent is exited through a return statement it will not do a full swap, it will just set back the parameter value to the old state, not store the current state. /Stefan