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: Re: Document top-level pseudo-hygiene Date: Sun, 26 Jan 2014 23:50:34 -0500 Message-ID: <87r47ugh9h.fsf@netris.org> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1390798444 18210 80.91.229.3 (27 Jan 2014 04:54:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jan 2014 04:54:04 +0000 (UTC) Cc: guile-devel@gnu.org To: "Andy Wingo" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jan 27 05:54:11 2014 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W7eD1-0002zl-1p for guile-devel@m.gmane.org; Mon, 27 Jan 2014 05:54:07 +0100 Original-Received: from localhost ([::1]:57429 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7eD0-0005qR-8S for guile-devel@m.gmane.org; Sun, 26 Jan 2014 23:54:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7eCs-0005pR-KJ for guile-devel@gnu.org; Sun, 26 Jan 2014 23:54:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7eCm-0001yS-LN for guile-devel@gnu.org; Sun, 26 Jan 2014 23:53:58 -0500 Original-Received: from world.peace.net ([96.39.62.75]:33588) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7eCm-0001y3-C6 for guile-devel@gnu.org; Sun, 26 Jan 2014 23:53:52 -0500 Original-Received: from ip72-221-68-65.ri.ri.cox.net ([72.221.68.65] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1W7eCE-0002FU-1B; Sun, 26 Jan 2014 23:53:18 -0500 In-Reply-To: (Andy Wingo's message of "Sun, 26 Jan 2014 14:08:50 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x 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:16850 Archived-At: Hi Andy, "Andy Wingo" writes: > commit 03dfed840b377a72191b6f125c106fdfd9e90a21 > Author: Andy Wingo > Date: Fri Jan 24 12:34:26 2014 +0100 > > Document top-level pseudo-hygiene > > * doc/ref/api-macros.texi (Hygiene and the Top-Level): Add a section > documenting our pseudo-hygienic top-level names. As I've said before, I strenuously object to these novel semantics that you've invented. I believe this would be an ugly wart on Guile that we would have to support indefinitely, in violation of the standards, because its existence would encourage people to write code that depends upon it. > +If introduced top-level identifiers ``escape'' a module, in whatever > +way, they then form part of the binary interface (ABI) of a module. It > +is unacceptable from an engineering point of view to allow the ABI to > +change randomly. (It also poses practical problems in meeting the > +recompilation conditions of the Lesser GPL license, for such modules.) I understand the problem you are trying to solve. Please allow me to make a counter-proposal: > +For this reason many people prefer to never use identifier-introducing > +macros at the top-level, instead making those macros receive the names > +for their introduced identifiers as part of their arguments, or to > +construct them programmatically and use @code{datum->syntax}. Yes, this is exactly what we must teach people to do when an introduced toplevel identifier would cross a module boundary. It is the only way to completely solve the ABI problem. Your proposal not only violates the standards, but also fails to solve the ABI problem adequately. The problem is that if a library author needs to change any of the macro uses in their library, then the toplevel identifiers introduced by these macro uses will also change, and thus break the ABI. To make this more concrete, consider the example you used in the docs: (define-syntax-rule (defconst name val) (begin (define t val) (define-syntax-rule (name) t))) Now suppose that a library contains the following macro use: (defconst supported-srfis '(1 4 13 14 16 23 30 39 46)) Your proposed solution means that the library author cannot add to this list without unintentionally breaking their ABI. This is a mistake that an author might easily make, and your proposal not only does nothing to solve it, but encourages authors to write code that will lead to this mistake. In this case, what the library author really needs is for 't' to have a name derived from 'name', but ignoring 'val'. Of course, there's no way for Guile to read the author's mind. The author must make this decision explicitly. Now, to reduce the danger that a library author might unwittingly make the mistake you're (rightly) worried about, I suggest that we rig the compiler to issue a warning whenever an introduced toplevel identifier crosses a module boundary. What do you think? Mark