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: hygiene and macro-introduced toplevel bindings Date: Mon, 28 Feb 2011 22:28:20 +0100 Message-ID: References: <87bp1xui8e.fsf@vir.lan> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1298928198 9780 80.91.229.12 (28 Feb 2011 21:23:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 28 Feb 2011 21:23:18 +0000 (UTC) Cc: guile-devel To: Andreas Rottmann Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Feb 28 22:23:13 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PuAYh-0002L4-WF for guile-devel@m.gmane.org; Mon, 28 Feb 2011 22:23:12 +0100 Original-Received: from localhost ([127.0.0.1]:49486 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PuAYh-000764-CP for guile-devel@m.gmane.org; Mon, 28 Feb 2011 16:23:11 -0500 Original-Received: from [140.186.70.92] (port=47501 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PuAYd-00073a-74 for guile-devel@gnu.org; Mon, 28 Feb 2011 16:23:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PuAYb-0004W7-Ox for guile-devel@gnu.org; Mon, 28 Feb 2011 16:23:07 -0500 Original-Received: from a-pb-sasl-sd.pobox.com ([64.74.157.62]:44804 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PuAYb-0004Vv-Kl for guile-devel@gnu.org; Mon, 28 Feb 2011 16:23:05 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id BA61547BA; Mon, 28 Feb 2011 16:24:22 -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=AAD3pkmTai9w+YfFMaK//ZR4mTQ=; b=gchCn+ YgsnMMK2v3k1IYgXTVE7k2nlZBw4ZOi5vJxNFLL34SbWVzz68Zew+Z63Mq4wvrOQ TjEuSBkejGVpVzaLeIYBpaFmL4de7yH4CPq4f+KI+5PL7rG4itzpon5mnypED9eG UFGlK50Xe1dd8xWBvCP9S9L4lY8A3pBTlgMkM= 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=XWn4dqZbYqq+7XJcVoodbBPbVMbgddDq mcMIHHcV2VWsqS+yYIsQgolfMFKrDEnEtuz3NHrqnV7I0+ogNkvYiXuouB0HtV8k AkuRRPsJiKjd6gSVrjvcwr9i7d0ThHcd5uzunwklFZ3md/buNk9Dbq5AIjR3xGzk XCspxu1So+U= 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 A5F3747B8; Mon, 28 Feb 2011 16:24:21 -0500 (EST) Original-Received: from unquote.localdomain (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 7E3F347B0; Mon, 28 Feb 2011 16:24:19 -0500 (EST) In-Reply-To: <87bp1xui8e.fsf@vir.lan> (Andreas Rottmann's message of "Mon, 28 Feb 2011 01:15:45 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) X-Pobox-Relay-ID: 1B90F986-4381-11E0-BD2D-AF401E47CF6F-02397024!a-pb-sasl-sd.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 64.74.157.62 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:11734 Archived-At: On Mon 28 Feb 2011 01:15, Andreas Rottmann writes: > Andy Wingo writes: > >> (define-accessor get-x set-x! 0) >> > This example serves to illustrate the issue, but I want to make clear > that there are situations where one cannot work around "cleanly" around > this issue Sure, a better example would be: (define-syntax define-syntactic-accessor (syntax-rules () ((_ getter setter init) (begin (define val init) (define-syntax getter (syntax-rules () ((_) val))) (define-syntax setter (syntax-rules () ((_ x) (set! val x)))))))) >> The issue is, what happens when this expression is expanded? Specifically, in Guile right now: (define-syntactic-accessor foo set-foo! #f) expands to: (define val #f) (define foo (make-syntax-transformer 'foo (lambda ...))) (define set-foo! (make-syntax-transformer 'foo (lambda ...))) If we generated a name for val, it would be (define val-234123 #f) ... where the syntax transformer lambdas reference that "unique" name. (Ensuring uniqueness is another issue.) >> Anyway, in Guile our modules have always been first-class entities. We >> never intern gensym'd names in modules, because who would do that? You >> put a name in a module because you want to be able to name it, either >> internally or externally, and gensym'd names don't make any sense >> without some sort of translation table, and Guile's first-class modules >> have no such table. >> > Sorry, I don't understand the part about the translation table, could > you clarify? For the same reason that we want to see real variable names in backtraces, and not de bruijn numbers, we would want to know what name "val-234123" corresponds to -- when traversing modules, in tab completion, etc. We would need a translation table for that purpose. > I agree that it makes no sense to allocate a named binding in the module > for `val' But you have to, I think. If that module that contained the above define-syntactic-accessor expansion exports "foo", then in another module you have: (define bar (lambda () (foo))) which expands to (define bar (lambda () val-234123)) Val needs to be named. > consider this: > > (define-accessor (get-foo set-foo! #f)) > (define-accessor (get-bar set-bar! #f)) Yep, bad. > Ideally, Guile would allocate an "anonymous binding" inside the module > -- a binding that has only a location, and lacking a visible name. Would that this were possible, but I hope the discussion above is sufficient to convince you that, under the covers at least, "val" needs a name. Separate compilation units refer to parts of each other by name. And then what happens if you recompile the module that defined the syntactic accessors? Your other, separately compiled module probably breaks. Then again this can happen more generally with macros. Guile could indeed introduce gensym'd names. It would be a bit nasty but it would work. But is it the right thing? Top-level names are interface, even if they are not (directly) exported from your module. I would be happier if we instead took care in choosing those names, instead of hiding them under the syntactic covers. Regards, Andy -- http://wingolog.org/