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: syntax-local-binding Date: Fri, 20 Jan 2012 17:03:23 -0500 Message-ID: <87obtyuj4k.fsf@netris.org> References: <874nvw99za.fsf@pobox.com> <87zkdo7uf5.fsf@pobox.com> <87sjjbvs12.fsf@pobox.com> <87sjjaunme.fsf@netris.org> <87r4yurruv.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1327097078 3135 80.91.229.12 (20 Jan 2012 22:04:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 20 Jan 2012 22:04:38 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jan 20 23:04:34 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 1RoMZV-0002gs-5W for guile-devel@m.gmane.org; Fri, 20 Jan 2012 23:04:33 +0100 Original-Received: from localhost ([::1]:53435 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoMZU-0001fG-It for guile-devel@m.gmane.org; Fri, 20 Jan 2012 17:04:32 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:53774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoMZS-0001ex-2t for guile-devel@gnu.org; Fri, 20 Jan 2012 17:04:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RoMZQ-0004Nw-P8 for guile-devel@gnu.org; Fri, 20 Jan 2012 17:04:29 -0500 Original-Received: from world.peace.net ([96.39.62.75]:40817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoMZQ-0004Nq-Js for guile-devel@gnu.org; Fri, 20 Jan 2012 17:04:28 -0500 Original-Received: from turntable.mit.edu ([18.160.0.29] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1RoMZJ-0000CT-LA; Fri, 20 Jan 2012 17:04:22 -0500 In-Reply-To: <87r4yurruv.fsf@pobox.com> (Andy Wingo's message of "Fri, 20 Jan 2012 22:23:04 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:13610 Archived-At: Andy Wingo writes: > On Fri 20 Jan 2012 21:26, Mark H Weaver writes: > >> Andy Wingo writes: >>> `lexical' >>> A lexically-bound variable. The value is a unique token (in >>> the sense of `eq?') identifying this binding. >>> >>> `macro' >>> A syntax transformer, either local or global. The value is >>> the transformer procedure. >> >> Ironically, `syntax-local-binding' renders the current simple >> implementation strategy of `the-environment' inadequate, because >> identifier-syntax is no longer sufficient to simulate a lexical. > > Why do you say that? Because it breaks your nice equivalence. For example: (let ((x 1)) (syntax-local-binding #'x)) is not equivalent to: (let ((x 1)) (local-eval '(syntax-local-binding #'x) (the-environment))) Put another way: if anyone uses `syntax-local-binding' to distinguish lexical variables from macros in some clever macro of theirs, this means that `local-eval' is now buggy with regard to their clever macro. >> in particular, I was hoping to change the binding representation of >> `syntax-rules' macros so that they are serializable. In particular, >> they would be represented by the `syntax-rules' form itself (the same >> one that psyntax currently passes to `primitive-eval' to produce the >> transformer procedure). A weak-key hash table would cache the compiled >> transformer procedures. >> >> This would allow (the-environment) to capture locally-bound >> `syntax-rules' macros. Unfortunately, `syntax-local-binding', as >> currently documented, now makes this impossible. > > Why do you think that? The procedures do carry metadata; I understood > that that was your strategy, to use the serialization of the > syntax-rules form in the procedure metadata. Well, this was in the context of a new strategy where psyntax would include a new core form called `call-with-current-local-expander' that calls its parameter (a procedure or macro) with a procedure that accepts an expression and returns an expanded form. In this case, the most straightforward implementation would simply serialize the (r w mod) structures directly. Toward that end, I was thinking it would be nice to keep those structures serializable. The only part that's not currently serializable are the transformer procedures for local macros. Thus the change in representation. More specifically: instead of attaching procedure properties/metadata to the transformer procedures as is currently done, that information would be put directly into the binding. An alist would probably make the most sense. The source code of the macro (whatever's currently passed to `primitive-eval') would also be included. This may or may not be a good idea, I dunno. I haven't fully thought it through. However, that's not the point. The point is that by exposing these details in the API, you are constraining our ability to make changes of this kind. I think that's very unfortunate. Mark