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

[Andy Wingo]

Hi!

Thanks for thinking this through!

On Thu 30 Jun 2011 23:27, address@hidden (Ludovic Courtès) writes:

> 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.”)

Indeed, no.  I think we need to fix fluids.

>>   (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).  :-)

Yes!  However that doesn't help us in boot-9 :)

> 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?

Third time's the charm, as they say... here's the deal.  `with-fluids'
is fairly efficient, because its body does not need to be allocated as a
closure, but it doesn't provide you any guarantees about the values
bound to the fluids.  Parameter objects are better in that way, because
their converter can check the values.  Parameterize is just as short as
with-fluids, but preserves this correctness property, so it's a good
thing.

However parameterize was not as efficient as `with-fluids', because its
body must be a closure.  This version fixes that, so perhaps parameters
are the thing now.

Also, (fluid-ref x) is more typing than (x), and the dance needed to
define a fluid, init val, and accessor takes longer than (make-parameter
'foo).  So parameters are a win IMO.

>> 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.

Would you like users to be able to (fluid-set! %current-input-port
'not-a-port)?  Or to (with-fluids ((%current-input-port 'foo)) ...) ?
Probably not.  I think that we should be switching to parameters for
user-facing dynamic bindings.  Fluids are to dynamic bindings what
variables are to toplevel bindings: useful building blocks, but not
usually what you want to give to the user.

WDYT? :)

Andy
-- 
http://wingolog.org/