[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) |
Hello!
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
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/
- Re: How can I tell guile to shut up? ;), Andy Wingo, 2011/07/01
- Re: How can I tell guile to shut up? ;), Andy Wingo, 2011/07/01
- Re: How can I tell guile to shut up? ;), Ludovic Courtès, 2011/07/01
- Re: How can I tell guile to shut up? ;), Andy Wingo, 2011/07/01
- Re: How can I tell guile to shut up? ;), Ludovic Courtès, 2011/07/04
- Fluids vs parameters: which API is better?, Mark H Weaver, 2011/07/18
- Re: Fluids vs parameters: which API is better?, Andy Wingo, 2011/07/19
- Re: Fluids vs parameters: which API is better?, BT Templeton, 2011/07/24
- Re: Fluids vs parameters: which API is better?, Ludovic Courtès, 2011/07/25
- Re: Fluids vs parameters: which API is better?,
Andy Wingo <=