From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: hygiene and macro-introduced toplevel bindings Date: Mon, 28 Feb 2011 16:49:43 -0500 Message-ID: References: <87bp1xui8e.fsf@vir.lan> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1298929798 19486 80.91.229.12 (28 Feb 2011 21:49:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 28 Feb 2011 21:49:58 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Feb 28 22:49:54 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 1PuAyX-00088b-9Z for guile-devel@m.gmane.org; Mon, 28 Feb 2011 22:49:53 +0100 Original-Received: from localhost ([127.0.0.1]:41264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PuAyW-00048Z-PI for guile-devel@m.gmane.org; Mon, 28 Feb 2011 16:49:52 -0500 Original-Received: from [140.186.70.92] (port=34252 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PuAyP-00048U-SX for guile-devel@gnu.org; Mon, 28 Feb 2011 16:49:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PuAyO-0008Tk-GG for guile-devel@gnu.org; Mon, 28 Feb 2011 16:49:45 -0500 Original-Received: from mail-yi0-f41.google.com ([209.85.218.41]:42431) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PuAyO-0008Tg-Cb for guile-devel@gnu.org; Mon, 28 Feb 2011 16:49:44 -0500 Original-Received: by yib2 with SMTP id 2so2189505yib.0 for ; Mon, 28 Feb 2011 13:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3UEzaDNCijh+f1SpKYXYzxgxsCEF45sRdeq3MsudQ7I=; b=XXsYyprF72O5s4RUv9rDQKlkgVklQhzMffX2iVg8dyS2A8hPVTo8ZRuiYpEw5099ZQ 1XcS9XxOo7HG1yOWoNhhSn9ILQDNoY7bDG1BGx7qTLbkauWsLJQANC9Wy1Mjqf8lNnCP XNr2VU34m9SN3F76VJ3cikAEm7Vw3Lc8v4yyk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Ihl+/ZqxQFQsJSW2XXkIa7RMUP/RF0NwXWER/ZoFxkbGWfOTQiARE+90oGhpKf4taH sahU1USD6mM4Jq/KmKb+vAikk7XQE4PUa+kPjlJVmxWX5bHigCDa5EA9q6P4SGNJbZ5s gULfJC0gqMixFkw5l6uQ5ZMGpMxzt9KC3Meic= Original-Received: by 10.150.31.3 with SMTP id e3mr7895037ybe.255.1298929783555; Mon, 28 Feb 2011 13:49:43 -0800 (PST) Original-Received: by 10.146.84.3 with HTTP; Mon, 28 Feb 2011 13:49:43 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: Dut4OBeG9Rs8pej6hJFTR9mJlmw X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.218.41 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:11735 Archived-At: Hello all, I believe what I'm saying is equivalent to what Andreas said, but let me put it in this way: I think the Right Thing to do is to change what we think of as a name - instead of a name being a symbol, a name would be a symbol plus the environment it was defined in (which is what a syntax object is, right?). That would solve this issue, because each expansion of the macro would get a different environment (this must happen because this is already how hygiene works, right?). Then ideally we would modify the backtrace code to print these things nicely, so it would say something like: val (defined in call to define-syntactic-accessor, file.scm:53) =3D 5 val (defined in call to define-syntactic-accessor, file.scm:55) =3D 7 And then you'd probably special-case it so that each module had a "top-level environment" which didn't print with parentheses, which would hold things that were not defined in any macro, so you could also have val =3D 9 for the result of running (define val 9) at the module's top level. Does this sound right to people? Noah On Mon, Feb 28, 2011 at 4:28 PM, Andy Wingo wrote: > On Mon 28 Feb 2011 01:15, Andreas Rottmann writes: > >> Andy Wingo writes: >> >>> =A0 (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: > > =A0(define-syntax define-syntactic-accessor > =A0 =A0(syntax-rules () > =A0 =A0 =A0((_ getter setter init) > =A0 =A0 =A0 (begin > =A0 =A0 =A0 =A0 (define val init) > =A0 =A0 =A0 =A0 (define-syntax getter > =A0 =A0 =A0 =A0 =A0 (syntax-rules () > =A0 =A0 =A0 =A0 =A0 =A0 ((_) val))) > =A0 =A0 =A0 =A0 (define-syntax setter > =A0 =A0 =A0 =A0 =A0 (syntax-rules () > =A0 =A0 =A0 =A0 =A0 =A0 ((_ x) (set! val x)))))))) > >>> The issue is, what happens when this expression is expanded? > > Specifically, in Guile right now: > > =A0(define-syntactic-accessor foo set-foo! #f) > > expands to: > > =A0(define val #f) > =A0(define foo (make-syntax-transformer 'foo (lambda ...))) > =A0(define set-foo! (make-syntax-transformer 'foo (lambda ...))) > > If we generated a name for val, it would be > > =A0(define val-234123 #f) > =A0... > > 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. =A0= We >>> never intern gensym'd names in modules, because who would do that? =A0Y= ou >>> 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. =A0We 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. =A0If that module that contained the above > define-syntactic-accessor expansion exports "foo", then in another > module you have: > > =A0(define bar (lambda () (foo))) > > which expands to > > =A0(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. =A0Separate compilation units refer to parts of each other by > name. > > And then what happens if you recompile the module that defined the > syntactic accessors? =A0Your other, separately compiled module probably > breaks. =A0Then again this can happen more generally with macros. > > Guile could indeed introduce gensym'd names. =A0It would be a bit nasty > but it would work. =A0But is it the right thing? =A0Top-level names are > interface, even if they are not (directly) exported from your module. =A0= 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/ > >