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: Tue, 24 Jan 2012 21:30:29 -0500 Message-ID: <87ipk0qzsq.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> <87hazmrv15.fsf@netris.org> <87zkdem58t.fsf@pobox.com> <87d3a9mjcy.fsf@pobox.com> <874nvls04f.fsf@netris.org> <87ipk0lrs2.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1327458697 15581 80.91.229.12 (25 Jan 2012 02:31:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 25 Jan 2012 02:31:37 +0000 (UTC) Cc: Peter TB Brett , guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jan 25 03:31:32 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 1Rpse3-00064X-UW for guile-devel@m.gmane.org; Wed, 25 Jan 2012 03:31:32 +0100 Original-Received: from localhost ([::1]:56630 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rpse3-0003xx-5Z for guile-devel@m.gmane.org; Tue, 24 Jan 2012 21:31:31 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:51598) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rpse0-0003xe-Nk for guile-devel@gnu.org; Tue, 24 Jan 2012 21:31:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rpsdz-0003NJ-8t for guile-devel@gnu.org; Tue, 24 Jan 2012 21:31:28 -0500 Original-Received: from world.peace.net ([96.39.62.75]:41289) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rpsdz-0003NC-2q for guile-devel@gnu.org; Tue, 24 Jan 2012 21:31:27 -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 1Rpsds-0006Do-Ia; Tue, 24 Jan 2012 21:31:20 -0500 In-Reply-To: <87ipk0lrs2.fsf@pobox.com> (Andy Wingo's message of "Tue, 24 Jan 2012 22:22:37 +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:13668 Archived-At: Andy Wingo writes: > In the spirit of diffusing tension here, feel free to imagine all of my > words as coming from Mr. Collins for the duration of this thread ;-) Hehe :) > On Tue 24 Jan 2012 14:25, Mark H Weaver writes: > >> Andy Wingo writes: >> >>> None of the interfaces that I proposed leak internal psyntax >>> representations. >> >> `syntax-local-binding' leaks the internal representations used for >> bindings. > > You mean, whether something is a lexical, or a macro, or a global, or > whatever; OK. That's actually not what I meant, although I'm not convinced that we fully understand the implications of exposing even that much. One thing that is already clear is that `identifier-syntax' and `local-eval' were previously capable of emulating variables perfectly before, whereas in the presence of `syntax-local-binding' they no longer are. This is a perfect example of how added flexibility in one aspect can lead to _reduced_ flexibility in other aspects. I think we need more time to consider the implications of this. However, the more serious problem, and the one I was actually talking about, is the _second_ value returned by `syntax-local-binding', which exposes the representations of bindings stored in the cdrs of the psyntax `r' alist. > Let me offer another example of its utility: writing a macro stepper. It's not the least bit surprising that exposing internal implementation details enables the creation of all kinds of nifty things as external programs that would ordinarily need to be internal. This is perfectly obvious. However, as you wisely said to me when I posted my first `local-eval' evaluator-only implementation, this stuff has a cost, and it has to justify itself. I assumed you meant the maintenance cost of supporting this advanced functionality indefinitely, and the constraints that it places on the freedom of future implementors. Was I right? In retrospect, based on your recent behavior, I wonder if that's what you meant or if you were talking about something completely different, because you seem to have completely abandoned your original restraint, and have now gone much farther than I would ever dare to go. Indeed, as you can see, I am very unhappy about how far you have gone with this. > Perhaps, though, at this point we're just going to have to agree to > disagree; This is a euphemism for "sorry, but we're doing it my way". Multiple people here have expressed grave concerns about your approach, and not a single person has publicly expressed their support for adding all of these new interfaces you've designed. Even Ludovic has remained silent. And yet you apparently intend to rush all of this stuff into 2.0.4. After all, nothing could be worse than having `the-environment' in psyntax, even for single release. Is this your idea of a consensus process, which you so often advocate? Mark