guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: redo-safe-variables and redo-safe-parameters


From: Noah Lavine
Subject: Re: redo-safe-variables and redo-safe-parameters
Date: Wed, 27 Mar 2013 17:44:32 -0400

Hello,

On Wed, Mar 27, 2013 at 12:15 PM, Stefan Israelsson Tampe <address@hidden> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]