From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a Date: Sun, 15 Jan 2012 12:44:12 +0100 Message-ID: <87aa5p8a2b.fsf@pobox.com> 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=us-ascii X-Trace: dough.gmane.org 1326646873 19605 80.91.229.12 (15 Jan 2012 17:01:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 15 Jan 2012 17:01:13 +0000 (UTC) Cc: guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Jan 15 18:01:08 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 1RmTS7-000121-TN for guile-devel@m.gmane.org; Sun, 15 Jan 2012 18:01:08 +0100 Original-Received: from localhost ([::1]:51268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmTS4-0003Tk-EC for guile-devel@m.gmane.org; Sun, 15 Jan 2012 12:01:04 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:41378) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmTRu-0003GA-HC for guile-devel@gnu.org; Sun, 15 Jan 2012 12:01:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RmTRp-0001q8-VS for guile-devel@gnu.org; Sun, 15 Jan 2012 12:00:52 -0500 Original-Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62]:38510 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmTRp-0001q2-Qd for guile-devel@gnu.org; Sun, 15 Jan 2012 12:00:49 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 595DC85C0; Sun, 15 Jan 2012 12:00:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=dC4mALzU18y4crILjFL9ZJAb8s0=; b=q+0qMB PJZqc0KBCMuNFqZlAKWsDPJ4E2jnc2CyG1XsGkTOd82QgqbwTfftBiwJBYSjt83C se0qMXMEJJnUlEWrmch9QsHbV9qbVDoQ9I1YdWqeVbN4RwzTXaS8WOVJLJ5+MFn4 5Tj9qqB0I2keCMM9VEaBnzBjpwzrowGzHk5a4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=MWNLIwfahnpnxWiIzmQQc1rW2RiD3A0r 6V18j24pMlhn0SPeg4YhKjW4ZLvzZTuVd8CA9ihN9IJ1LlzHrB3BedS1cwYuUy9z ZQIYY9tWdh+USV/v/Rce6/gBJ8i0ivS4S8ldrajE1o8w5HCPDoj/R9VPwA7KJ1H1 qG38wXrjdts= Original-Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 5320E85BF; Sun, 15 Jan 2012 12:00:49 -0500 (EST) Original-Received: from badger (unknown [90.164.198.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 7D4AB85BE; Sun, 15 Jan 2012 12:00:48 -0500 (EST) In-Reply-To: <87hazy58ct.fsf@netris.org> (Mark H. Weaver's message of "Sat, 14 Jan 2012 15:37:06 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-Pobox-Relay-ID: 7912A936-3F9A-11E1-A60B-65B1DE995924-02397024!a-pb-sasl-sd.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 74.115.168.62 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:13516 Archived-At: Hi Mark, On Sat 14 Jan 2012 21:37, Mark H Weaver writes: > If a top-level variable needs to be expanded in user code, then you'd > better explicitly choose a stable name for it. Indeed, this is the best solution, for interface stability. But what should happen when users do introduce top-level variables in their macros, against our recommendations? My point is that the answer cannot be, "generate a truly random identifier". Simply advising users not to introduce bindings is not a great answer. > In the general case, where a macro may have been considerably reworked > from one version to the next, it's _impossible_, even in principle, > for the system to reliably decide the correspondence between top-level > gensyms in the new code vs the old code. Even your method is only a > heuristic that will often do the wrong thing, in both directions: it > will cause unintended name collisions in R5RS standard code, and it > will also sometimes change the name of a top-level when you didn't > want it to. Of course. It's a heuristic. We document the heuristic and move on, no? If users really find themselves caring about this, they will have to learn the heuristic. > There's another option: we could properly track the compile-time > dependencies of each module, and automatically consider a .go file stale > if _any_ of its compile-time dependencies are newer than it. We do need to do this, yes. This would be a great thing to add, once we switch to ELF as our format of compiled files. (You would add a section for this.) > Furthermore, we could provide distros with the necessary infrastructure > to automatically recompile guile modules as needed after package > upgrades. That is orthogonal to this question. Recompilation can be triggered on package dependencies, instead of embedded expansion dependencies. That's what I was planning on doing for the guildhall, for example. Regards, Andy -- http://wingolog.org/