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: Mon, 23 Jan 2012 16:03:34 -0500 Message-ID: <87hazmrv15.fsf@netris.org> References: <874nvw99za.fsf@pobox.com> <87zkdo7uf5.fsf@pobox.com> <87sjjbvs12.fsf@pobox.com> <87sjjaunme.fsf@netris.org> <87r4yurruv.fsf@pobox.com> <87obtyuj4k.fsf@netris.org> <871uqqpfoo.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1327352693 26844 80.91.229.12 (23 Jan 2012 21:04:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 Jan 2012 21:04:53 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jan 23 22:04:49 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 1RpR4I-0001Aw-UB for guile-devel@m.gmane.org; Mon, 23 Jan 2012 22:04:47 +0100 Original-Received: from localhost ([::1]:34359 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpR4I-0003mo-Fj for guile-devel@m.gmane.org; Mon, 23 Jan 2012 16:04:46 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:39442) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpR4F-0003mh-CG for guile-devel@gnu.org; Mon, 23 Jan 2012 16:04:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpR4C-0007Og-O3 for guile-devel@gnu.org; Mon, 23 Jan 2012 16:04:43 -0500 Original-Received: from world.peace.net ([96.39.62.75]:39378) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpR4C-0007O1-KW for guile-devel@gnu.org; Mon, 23 Jan 2012 16:04:40 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1RpR3w-0001O4-17; Mon, 23 Jan 2012 16:04:24 -0500 In-Reply-To: <871uqqpfoo.fsf@pobox.com> (Andy Wingo's message of "Mon, 23 Jan 2012 17:05:43 +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:13650 Archived-At: Andy Wingo writes: > On Fri 20 Jan 2012 23:03, Mark H Weaver writes: > >> (let ((x 1)) >> (syntax-local-binding #'x)) >> >> is not equivalent to: >> >> (let ((x 1)) >> (local-eval '(syntax-local-binding #'x) (the-environment))) > > Indeed; bummer! I think, though, that this is simply a consequence of > giving more power to macro writers. > > It is analogous in some ways to the changes that identifier-syntax > introduce into macro writing: with identifier-syntax, one can no longer > write a code walker with syntax-rules pattern matching, as single > identifiers may expand out to complicated expressions, possibly even > with side effects. This is false. Macros are always expanded _before_ any of their arguments are expanded. Therefore, a code walker sees the unexpanded forms, including any "simulated variables" bound by identifier-syntax. >>> 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. > > I have been staring at this empty page here for a little while, writing > and re-writing, but I can't get over a feeling that I really don't want > this kind of work in psyntax itself. Your priorities are reversed from what they ought to be. What you _should_ be worried about is making commitments in our API that we must continue to support forever. This is a _real_ problem, since it constrains our ability to modify our implementation in the future. Putting the `the-environment' in psyntax is, at worst, a stylistic issue. Whether it belongs there is a matter of taste, but however strongly you may feel about that, it is a purely _internal_ implementation issue. The really important thing is that it commits us to _nothing_. There's nothing stopping us from radically reimplementing it later. In particular, there's nothing stopping us from moving it out of psyntax later. Guile has been in existence for a couple of decades already, and I hope that it will be actively used for many decades to come. With that in mind, please consider the long view. One of the reasons Scheme has lasted so long is because it tries exceptionally hard to hide internal implementation details. Implementations that expose too much internal detail may derive a short-term benefit from doing so, but it comes at the price of eventual calcification: there comes a time when implementations that expose too much become unable to make significant internal structural changes. Please consider this. I feel that your mind has become closed to my arguments. Mark