Hi Andy,
Andy Wingo <wi...@pobox.com> writes:
> So I am optimistic regarding our ability to gradually change over to
> parameters, if you are in agreement that parameters are the interface
> that we should export.
I'm sorry to throw a monkey wrench into this nice plan, but I would like
to briefly argue that fluids are the far superior interface.
>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). Granted, this requires an assumption that
`fluid-ref' has not been set to something else, but we're already making
similar assumptions for many other common operations, and there are
various ways we can manage these assumptions more cleanly in the future.
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.
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.
What do you think?
Best,
Mark
