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

[Noah Lavine <noah.b.lavine@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2234 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2922 bytes --]