unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
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/



  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).