Hi Mark,
On Mon 18 Jul 2011 23:57, Mark H Weaver <[email protected]> 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/
