Re: Fluids vs parameters: which API is better?

[Andy Wingo <wingo@pobox.com>]

Hello!

On Mon 25 Jul 2011 11:24, ludo@gnu.org (Ludovic Courtès) writes:

> BT Templeton <bpt@hcoop.net> skribis:
>
>> Andy Wingo <wingo@pobox.com> writes:
>
> [...]
>
>>> Here I disagree.  From the perspective of semantics and security, it's
>>> important to be able to make assertions as to the type of value returned
>>> by a procedure -- that (current-input-port) returns a port.  The same
>>> goes for (current-language) and all the other dynamic parameters.
>>> Parameters allow us to make guarantees like that.
>>
>> Why is it uniquely useful to be able to make these guarantees for
>> dynamically-bound values? Static/soft typing would be more generally
>> useful than parameters.
>
> I agree it’s not specific to dynamically-bound values.
>
> Andy mentioned that exporting, say, the fluid that underlies
> ‘current-output-port’ would be a problem because you could ‘fluid-set!’
> it to anything, which would lead to an obscure wrong-type-arg error
> sometime.
>
> OTOH it could be argued that this is no different with mutable global
> variables.

FWIW I think it's fine to export the fluid corresponding to
current-output-port -- and indeed the `parameter-fluid' accessor would
allow you to get at these values.  But, if you would like to provide a
minimal environment for untrusted code, you wouldn't provide
parameter-fluid (or struct-ref) to that code.

In Guile we have a tension between providing both hackability and
reliability.  We have many ways of resolving this tension -- modules,
convention, and tools among them.  In this case I would use all three --
expose the fluids you need to, but only if you need to; by convention,
avoid direct fluid access to other modules' fluids; and such access
should cause compile-time warnings (to give feedback to the user about
our conventions).

We should do the same for global variables, btw.  Set! to a variable
exported by another module should produce a warning.

As you mention BT, typing (and contracts) can help too.  We don't have
them currently, but that's no reason to eschew the tools that we do
have.

>> Also, I'd prefer it if parameters used a type predicate or a type
>> specifier object instead of a conversion procedure. ISTM that the
>> current interface conflates type checking and coercion.
>
> Well, Andy’s proposal is similar to SRFI-39 and I find it convenient
> this way.

In addition, this step does not preclude type specifier objects, were
Guile to get them at some point.  They can be defined as wrappers to
`make-parameter' et al.  Racket is really leading the way here, I
think; do read Findler's contracts work if you have an interest in such
things.

Andy
-- 
http://wingolog.org/