Hi! Andy Wingo <wi...@pobox.com> 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’.
