From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a Date: Sun, 15 Jan 2012 00:40:08 +0100 Message-ID: <874nvxkg4n.fsf@gnu.org> References: <87boskzj8i.fsf@netris.org> <871utgcr4g.fsf@pobox.com> <87y5vox6wh.fsf@netris.org> <87k471m6o9.fsf@pobox.com> <878vngwwej.fsf@netris.org> <87y5tklo44.fsf@pobox.com> <87hazy58ct.fsf@netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1326584433 11525 80.91.229.12 (14 Jan 2012 23:40:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 14 Jan 2012 23:40:33 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Jan 15 00:40:29 2012 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 1RmDD1-0005vj-QF for guile-devel@m.gmane.org; Sun, 15 Jan 2012 00:40:28 +0100 Original-Received: from localhost ([::1]:35306 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmDD1-0004Hx-3I for guile-devel@m.gmane.org; Sat, 14 Jan 2012 18:40:27 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:35611) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmDCx-0004Hh-R8 for guile-devel@gnu.org; Sat, 14 Jan 2012 18:40:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RmDCw-0007Ca-4H for guile-devel@gnu.org; Sat, 14 Jan 2012 18:40:23 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:54960) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmDCv-0007CS-Nq for guile-devel@gnu.org; Sat, 14 Jan 2012 18:40:22 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RmDCt-0005sR-W0 for guile-devel@gnu.org; Sun, 15 Jan 2012 00:40:19 +0100 Original-Received: from reverse-83.fdn.fr ([80.67.176.83]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Jan 2012 00:40:19 +0100 Original-Received: from ludo by reverse-83.fdn.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Jan 2012 00:40:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 68 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: reverse-83.fdn.fr X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 26 =?iso-8859-1?Q?Niv=F4se?= an 220 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux) Cancel-Lock: sha1:clE+p6Y67aTQVbTFdNNZ1c0bU9I= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:13510 Archived-At: Hello! Mark H Weaver skribis: > Andy Wingo writes: > >> On Wed 16 Nov 2011 04:58, Mark H Weaver writes: >> >>> I think there are better ways to address this problem. I will explore >>> these in another email. >> >> I look forward to this. Please be sure to address the following issues: >> >> * Debian upgrading guile to a newer version, without recompiling >> guile-foo which depends on a hygienically introduced identifier. >> >> * A user modifying a Scheme file from Guile, in the spirit of the >> LGPL, and expecting it to work with program Foo, without recompiling >> Foo (again, in the spirit of the LGPL). > > If we must avoid the recompilations, then I see only one solution: > simply refrain from introducing hygienic top-level identifiers in the > expansions of public interfaces. IMHO, this isn't so bad. If a > top-level variable needs to be expanded in user code, then you'd better > explicitly choose a stable name for it. That’s right. However, in some cases, one may want to write a macro, that introduces an identifier that’s really an implementation detail, and something the author does not want users to bother with. See, for instance, ‘define-wrapped-pointer-type’. Initially, I would have liked to not have a TYPE-NAME argument, because it’s not necessary for the user, and really an implementation detail. Yet, producing a hygienic top-level name wasn’t possible, so the TYPE-NAME argument had to be kept. This is acceptable in this example, but one could probably come up with use cases where it’s more embarrassing. > If you want the name to be programmatically based on some or all of > the macro arguments, this can already be done using `symbol-append', > `datum->syntax' et al. Yes, but it’s not hygienic. [...] > To be more specific: I think we need to record, in every syntax > transformer bound at top-level, the name of the module where it's bound. > Then, within the dynamic extent of `compile-file', (probably using a > fluid) we'd need to accumulate the set of modules whose macro > transformers are used during compilation of the file. This set of > modules (the compile-time dependencies) would be included in the .go > file. Sounds like a good plan! > I think we need this _anyway_. Right now, if you change the way an > exported macro works (for example a macro that defines a record type), > you must _manually_ force recompilation of other modules that expand > that macro. I actually ran into this problem while working on adding > new compiler environment types. Yes, that’s something one quickly encounters when incrementally modifying code with Geiser, for instance. Thanks, Ludo’.