[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: |
Tue, 19 Jul 2011 10:19:29 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) |
Hi Mark,
On Mon 18 Jul 2011 23:57, Mark H Weaver <address@hidden> writes:
> From an efficiency perspective, it is much more straightforward and
> reliable for a compiler to understand what operation is done by
> (fluid-ref x) than (x).
This is true.
> More generally, from a perspective of semantics and security, it is
> preferable for a program to apply a known operation (e.g. `fluid-ref')
> to some data, than to call the `data' as a procedure and ask it to do
> something. Yes, there are cases when the flexibility of message passing
> is worthwhile, but there are significant disadvantages. Once you do
> this, you can no longer analyze the behavior of a procedure without
> knowing a lot about the data itself.
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.
> In this particular case I think it would be a shame to enshrine the
> disadvantages of message passing into our API, on such a fundamentally
> important set of primitives.
Fluids will still exist, of course. But I think you are conflating two
things:
1) Optimizability. I don't think this matters much TBH. One could
define an inlinable parameter and have all the safety guarantees of
parameters compiling down to a fluid-ref.
2) Perspicacity (from a tools POV?). Again, not much has changed
here. Parameters can be recognized as such by any tool. In the
general case you need whole-program analysis to recover the
bindings of fluids anyway.
Parameters have a long history in Scheme, from current-input-port to
SRFI-39, to R6RS and now probably in R7RS. I think they're close to the
right thing, and given that you can get the fluids from the parameters
if you want, there's not much of a down-side. And, they are more terse
to use.
Have I convinced you now? :-)
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 <=
- 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, 2011/07/25