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 17:44:32 -0400 Message-ID: References: <13378334.Jv25yq6OaM@warperdoze> <36877746.VlrjcRTRXD@warperdoze> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec520f083b236e804d8eef228 X-Trace: ger.gmane.org 1364420706 7117 80.91.229.3 (27 Mar 2013 21:45:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Mar 2013 21:45:06 +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 22:45:31 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 1UKy9t-0001yA-9o for guile-devel@m.gmane.org; Wed, 27 Mar 2013 22:45:25 +0100 Original-Received: from localhost ([::1]:37826 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKy9U-00017a-SX for guile-devel@m.gmane.org; Wed, 27 Mar 2013 17:45:00 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKy9R-00017J-F9 for guile-devel@gnu.org; Wed, 27 Mar 2013 17:44:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKy9O-0003ux-4R for guile-devel@gnu.org; Wed, 27 Mar 2013 17:44:57 -0400 Original-Received: from mail-pb0-f54.google.com ([209.85.160.54]:41474) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKy9N-0003tu-Rv for guile-devel@gnu.org; Wed, 27 Mar 2013 17:44:54 -0400 Original-Received: by mail-pb0-f54.google.com with SMTP id rq13so1436420pbb.13 for ; Wed, 27 Mar 2013 14:44:52 -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=s6wY/DjsLgh2HxJIA+652E9IJpOVu+7I1O00C0ahXhQ=; b=hx/3S99lNfluwx7uXWplpIFgxnrFKPfhltkcEIgNkiJWD3nZxUSklcETVYDADbfuWk aOuE5p6C3kwmyfKinGGx9JpNAanVDamwz/NBJ52mc9aYJwssi7fR5WOI/c1rXn79nkI0 +/NM1BznSFtS80Yw6dqd4CPRwzMkHRt6tKkNV9WB628PEm57FuRE1MhQiXxUh8pCMBrx Syr0kSfRb8rCpn94p7Txtkv6PtM4Qk/TL1OHnaMZNyP79iY2qdnewcuPqMmYS/CkWvZx WAdvga6OX4xoyIsk3PYNZocejXh9c/vEAtMHgcLAAugHM8060nRbpOuETtx1A3gwdEHF eZoQ== X-Received: by 10.68.14.165 with SMTP id q5mr31311222pbc.125.1364420692409; Wed, 27 Mar 2013 14:44:52 -0700 (PDT) Original-Received: by 10.68.157.42 with HTTP; Wed, 27 Mar 2013 14:44:32 -0700 (PDT) In-Reply-To: <36877746.VlrjcRTRXD@warperdoze> X-Google-Sender-Auth: axVb7KVo1UZi8T3GZMIJf_4YyG8 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.160.54 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:16039 Archived-At: --bcaec520f083b236e804d8eef228 Content-Type: text/plain; charset=ISO-8859-1 Hello, On Wed, Mar 27, 2013 at 12:15 PM, Stefan Israelsson Tampe < stefan.itampe@gmail.com> wrote: > 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? > It may be a better approach. If so, you can implement this with Guile's current support for fluids (or parameters, probably, if you wanted to). Define (~ i) to be (fluid-ref i) and (set~ i x) to be (fluid-set! i x). You can even implement with-redo-variables this way, using something like (define-syntax with-redo-variables (syntax-rules (~) ((_ (((~ var) val) . rest) code ...) (let ((var (make-fluid))) (with-fluids ((var val)) (with-redo-variables rest code ...)))) ((_ ((var val) . rest) code ...) (let ((var val)) (with-redo-variables rest code ...))) ((_ () code ...) (begin code ...)))) And using the definitions of ~ and set~ above. I haven't tested that, so it probably doesn't work. I imagine that you could make it work with parameters pretty easily too. Since it's definable with such a simple macro, I don't think it's appropriate for a SRFI. To me, the more interesting point you've raised is the idea that Elisp variables should map to fluids rather than regular Scheme variables. That may be important of Elisp ever starts interacting with continuations. But that will require some more thought. I don't think it matters much now (if it did, presumably guile-emacs would have problems). Noah --bcaec520f083b236e804d8eef228 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

On Wed, Mar 27, 2013 at 12:15 PM, Stefan Israelsson Tampe = <stefan.itampe@gmail.com> wrote:
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?

=
It may be a better approach. If so, you can implement this with Guile&= #39;s current support for fluids (or parameters, probably, if you wanted to= ). Define (~ i) to be (fluid-ref i) and (set~ i x) to be (fluid-set! i x).<= br>
You can even implement with-redo-variables this way, using s= omething like

(define-syntax with-redo-variables
=A0 (syntax-rules (~)
=A0=A0=A0 ((_ (((~ var) val) . re= st) code ...)
=A0=A0=A0=A0 (let ((var (make-fluid)))
=A0=A0=A0= =A0=A0 (with-fluids ((var val))
=A0=A0=A0=A0=A0=A0=A0 (with-r= edo-variables rest code ...))))
=A0=A0=A0 ((_ ((var val) . re= st) code ...)
=A0=A0=A0=A0 (let ((var val))
=A0=A0=A0=A0=A0 (with-redo-variables rest code ...)))
<= div>=A0=A0=A0 ((_ () code ...)
=A0=A0=A0=A0 (begin code ...))= ))

And using the definitions of ~ and set~ above. I haven= 't tested that, so it probably doesn't work. I imagine that you cou= ld make it work with parameters pretty easily too.

Since it's definable with such a simple macro, I don't think it= 's appropriate for a SRFI.

To me, the more interestin= g point you've raised is the idea that Elisp variables should map to fl= uids rather than regular Scheme variables. That may be important of Elisp e= ver starts interacting with continuations. But that will require some more = thought. I don't think it matters much now (if it did, presumably guile= -emacs would have problems).

Noah

--bcaec520f083b236e804d8eef228--