[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fluids vs parameters: which API is better?

From: Andy Wingo
Subject: Re: Fluids vs parameters: which API is better?
Date: Mon, 25 Jul 2011 16:21:45 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)


On Mon 25 Jul 2011 11:24, address@hidden (Ludovic Courtès) writes:

> BT Templeton <address@hidden> skribis:
>> Andy Wingo <address@hidden> 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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]