[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

  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? :-)


reply via email to

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