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

[ludo@gnu.org (Ludovic Courtès)]

Hello!

Andy Wingo <wingo@pobox.com> skribis:

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

Yes, agreed.  I prefer parameters too, but I was concerned that using
parameters in Guile’s API would introduce an inconsistency, break the
rule of least surprise, etc.

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

OK, understood.

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

No, but OTOH, I *think* it would lead to a graceful type error sooner or
later, as opposed to a crash.

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

Yes, agreed in principle—though in practice variables can be set
arbitrarily.

The problem I have is that (1) I don’t see how we could migrate the
existing public fluids to parameters without breaking the API, and (2)
it’s unpleasant to my eye to have both fluids and parameters in the core
API.

WDYT?

Thanks,
Ludo’.