Re: How can I tell guile to shut up? ;)

[Ludovic Courtès]

Hi!

Andy Wingo <address@hidden> skribis:

>   4) Our fluids currently have problems with threads: if a thread not
>      spawned by a Guile thread enters Guile, its fluids are bound to
>      #f.  This should be fixed; in the meantime though we hack around
>      that with the (or ...) clause, which is not a hack that will work
>      for parameters (though perhaps it would, with a wrapper
>      procedure).

Does your parameter proposal intend to address this?  (My understanding
is “no.”)

>   (define <parameter>
>     ;; Three fields: the procedure itself, the fluid, and the converter.
>     (make-struct <applicable-struct-vtable> 0 'pwprpr))
>   (set-struct-vtable-name! <parameter> '<parameter>)
>
>   (define (parameter? x) (and (struct? x) (eq? (struct-vtable x) 
> <parameter>)))
>   (define (parameter-fluid p) (struct-ref p 1))
>   (define (parameter-converter p) (struct-ref p 2))

Maybe we should provide ‘define-applicable-record-type’ in
(srfi srfi-9 gnu).  :-)

>   (define* (make-parameter init #:optional (conv (lambda (x) x)))
>     (let ((fluid (make-fluid)))
>       (fluid-set! fluid (conv init))
v>       (make-struct <parameter> 0
>                    (case-lambda
>                      (() (fluid-ref fluid))
>                      ((x) (fluid-set! fluid (conv x))))
>                    fluid conv)))
>
>   (define-syntax parameterize
>     (syntax-rules ()
>       ((_ ((param value) ...) body body* ...)
>        (let ((p param) ...)
>          (with-fluids (((parameter-fluid p) ((parameter-converter p) value))
>                        ...)
>            body body* ...)))))

To me it looks like we’re adding a 3rd variation on the theme (well,
‘make-mutable-parameter’ already existed, but it’s not meant to be used,
is it?).

Personally, I’ve typically used the fluids API within Guile, for the
sake of consistency, and SRFI-39 elsewhere.  What does it buy us to use
our own ‘parameterize’ variants in parts of Guile?

[...]

> Then we somehow change the
> `current-input-port' binding to be a <parameter>

How about exposing the fluids the underlie ‘current-input-port’ &
co. instead?  This would allow the use of ‘with-fluids’ instead of
fiddling with ‘dynamic-wind’ and the like, while being consistent with
the rest of Guile.

Thanks,
Ludo’.