From: Andy Wingo <wingo@pobox.com>
To: Mark H Weaver <mhw@netris.org>
Cc: "Ludovic Courtès" <ludo@gnu.org>, guile-devel@gnu.org
Subject: Re: Fluids vs parameters: which API is better?
Date: Tue, 19 Jul 2011 10:19:29 +0200 [thread overview]
Message-ID: <87ipqyk7hq.fsf@pobox.com> (raw)
In-Reply-To: <87livvxnej.fsf_-_@yeeloong.netris.org> (Mark H. Weaver's message of "Mon, 18 Jul 2011 17:57:24 -0400")
Hi Mark,
On Mon 18 Jul 2011 23:57, Mark H Weaver <mhw@netris.org> 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/
next prev parent reply other threads:[~2011-07-19 8:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <99db88be1896528082d33a77ec4cadbe.squirrel@webmail.kapsi.fi>
2011-03-31 11:11 ` How can I tell guile to shut up? ;) Andy Wingo
2011-06-28 21:52 ` Andy Wingo
2011-06-30 1:24 ` Andreas Rottmann
2011-06-30 9:23 ` Andy Wingo
2011-06-30 21:27 ` Ludovic Courtès
2011-07-01 8:16 ` Andy Wingo
2011-07-01 13:04 ` Ludovic Courtès
2011-07-01 14:26 ` Andy Wingo
2011-07-04 13:24 ` Ludovic Courtès
2011-07-18 21:57 ` Fluids vs parameters: which API is better? Mark H Weaver
2011-07-19 8:19 ` Andy Wingo [this message]
2011-07-24 14:52 ` BT Templeton
2011-07-25 9:24 ` Ludovic Courtès
2011-07-25 14:21 ` Andy Wingo
2011-12-05 17:15 ` How can I tell guile to shut up? ;) Andy Wingo
2011-06-30 21:37 ` Ludovic Courtès
2011-07-01 8:03 ` Andy Wingo
2011-07-01 12:49 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ipqyk7hq.fsf@pobox.com \
--to=wingo@pobox.com \
--cc=guile-devel@gnu.org \
--cc=ludo@gnu.org \
--cc=mhw@netris.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).