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: Tue, 26 Mar 2013 18:36:46 -0400 Message-ID: References: <13378334.Jv25yq6OaM@warperdoze> <1767639.rWRbQJn65G@warperdoze> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec51dd609ade44f04d8db8f00 X-Trace: ger.gmane.org 1364337431 16354 80.91.229.3 (26 Mar 2013 22:37:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Mar 2013 22:37:11 +0000 (UTC) Cc: guile-devel To: Stefan Israelsson Tampe Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Mar 26 23:37:38 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 1UKcUr-0003j3-AF for guile-devel@m.gmane.org; Tue, 26 Mar 2013 23:37:37 +0100 Original-Received: from localhost ([::1]:43016 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKcUT-0008BM-BN for guile-devel@m.gmane.org; Tue, 26 Mar 2013 18:37:13 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48989) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKcUP-0008Ao-TB for guile-devel@gnu.org; Tue, 26 Mar 2013 18:37:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKcUO-0000cb-6O for guile-devel@gnu.org; Tue, 26 Mar 2013 18:37:09 -0400 Original-Received: from mail-pa0-f50.google.com ([209.85.220.50]:45113) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKcUN-0000ba-ST for guile-devel@gnu.org; Tue, 26 Mar 2013 18:37:08 -0400 Original-Received: by mail-pa0-f50.google.com with SMTP id bg2so1815917pad.23 for ; Tue, 26 Mar 2013 15:37:07 -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=LxnY0iXZaFEJ3vqQw3q20o9CLTWScHNMHyHwsndtc4k=; b=Huwf3LVUtaN+PmiIOR7ILtegkzibYKWr6gxZt7GJXk0fkKNbRQHvd4u2Ra8K1dzTYA EzJDV7obIBUcfh7edPB23bB8/raUQNuY3NbO2p3nmI4elPh2ch71MHJOOj9x5w9BT0Bk 09hC6oitqCqZ+/CMJljrxel8j9T9Q8UJamCZ2QG+2MIXUm4Uwq+6mCUczyy5dw5YZCY2 onKJTuXuC+E/xFbZiGpX7pco771giR3+sQavm0uoYdo/A+YZg6QotP9Nzv+BE3bdztja kBmDJ5Qh6OSUhBFKqJuovTeWTbzs/oa4MWWwjpxNB36eOs+fAtqGk6drSTcsym7lNeuK rgqw== X-Received: by 10.66.21.72 with SMTP id t8mr8338243pae.53.1364337426816; Tue, 26 Mar 2013 15:37:06 -0700 (PDT) Original-Received: by 10.68.157.42 with HTTP; Tue, 26 Mar 2013 15:36:46 -0700 (PDT) In-Reply-To: <1767639.rWRbQJn65G@warperdoze> X-Google-Sender-Auth: xiYz3PnB-ldur76NCoi85M0lCPs X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.220.50 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:16010 Archived-At: --bcaec51dd609ade44f04d8db8f00 Content-Type: text/plain; charset=ISO-8859-1 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. 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. 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. 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. Noah On Tue, Mar 26, 2013 at 6:01 PM, Stefan Israelsson Tampe < stefan.itampe@gmail.com> wrote: > 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 > > > --bcaec51dd609ade44f04d8db8f00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Okay. I don't see a use for number 1. C= ould you explain why it's important? It seems easier to me to just let = each variable have its own type.

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.

Also, in the example you gave earlier (in your third email in thi= s thread, beginning with "you need to combine fluids and dynamic wind = ..."), I don't see the difference between set! and set~ semantics.= It seems like the variables there have exactly the same semantics as fluid= s, except that you don't have to use (fluid-ref ...) to get their value= .

Noah


On Tue, Mar 26, 2013 at 6:01 PM, Stefan Israelsson Tampe <stefan.itampe@gmail.com> wrote:
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<= br> > what you want?
>
> I was confusing our fluids and the (fluid-let ...) construct from MIT<= br> > Scheme [0]. Are you looking for variables that behave the way
> fluid-let variables behave? (There's also a nice example on that p= age
> 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<= br> 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



--bcaec51dd609ade44f04d8db8f00--