From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Fluids vs parameters: which API is better? Date: Mon, 18 Jul 2011 17:57:24 -0400 Message-ID: <87livvxnej.fsf_-_@yeeloong.netris.org> References: <99db88be1896528082d33a77ec4cadbe.squirrel@webmail.kapsi.fi> <87y60lsjx5.fsf@pobox.com> <87r56cxgax.fsf@rotty.yi.org> <87r56bd656.fsf@pobox.com> <871uyb1030.fsf@gnu.org> <87zkky8lgi.fsf@pobox.com> <87tyb65eze.fsf@gnu.org> <87pqlu6prt.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1311026293 9353 80.91.229.12 (18 Jul 2011 21:58:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 18 Jul 2011 21:58:13 +0000 (UTC) Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jul 18 23:58:09 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QivpH-0004i2-Gr for guile-devel@m.gmane.org; Mon, 18 Jul 2011 23:58:07 +0200 Original-Received: from localhost ([::1]:34154 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QivpG-0000GF-IC for guile-devel@m.gmane.org; Mon, 18 Jul 2011 17:58:06 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:40184) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qivp5-0000Fq-7a for guile-devel@gnu.org; Mon, 18 Jul 2011 17:57:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qivp1-0005Oy-H6 for guile-devel@gnu.org; Mon, 18 Jul 2011 17:57:55 -0400 Original-Received: from world.peace.net ([96.39.62.75]:34444) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qivox-0005Na-6P; Mon, 18 Jul 2011 17:57:47 -0400 Original-Received: from ip68-9-118-38.ri.ri.cox.net ([68.9.118.38] helo=yeeloong.netris.org) by world.peace.net with esmtpa (Exim 4.69) (envelope-from ) id 1Qivog-0001h0-2w; Mon, 18 Jul 2011 17:57:30 -0400 Original-Received: from mhw by yeeloong.netris.org with local (Exim 4.72) (envelope-from ) id 1Qivoa-0001MV-I8; Mon, 18 Jul 2011 17:57:24 -0400 In-Reply-To: <87pqlu6prt.fsf@pobox.com> (Andy Wingo's message of "Fri, 01 Jul 2011 16:26:14 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:12666 Archived-At: Hi Andy, Andy Wingo 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