From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Peter TB Brett Newsgroups: gmane.lisp.guile.devel Subject: Re: syntax-local-binding Date: Tue, 24 Jan 2012 10:30:40 +0000 Organization: University of Surrey, Guildford, England Message-ID: 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1327401078 28689 80.91.229.12 (24 Jan 2012 10:31:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 Jan 2012 10:31:18 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jan 24 11:31:15 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 1Rpdek-0005dQ-As for guile-devel@m.gmane.org; Tue, 24 Jan 2012 11:31:15 +0100 Original-Received: from localhost ([::1]:53860 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rpdej-00073J-P1 for guile-devel@m.gmane.org; Tue, 24 Jan 2012 05:31:13 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:44680) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rpdeb-00072x-Pu for guile-devel@gnu.org; Tue, 24 Jan 2012 05:31:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpdeR-0004gr-T9 for guile-devel@gnu.org; Tue, 24 Jan 2012 05:31:05 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:52778) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpdeR-0004gl-JA for guile-devel@gnu.org; Tue, 24 Jan 2012 05:30:55 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RpdeQ-0005TO-8i for guile-devel@gnu.org; Tue, 24 Jan 2012 11:30:54 +0100 Original-Received: from 131.227.8.61 ([131.227.8.61]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Jan 2012 11:30:54 +0100 Original-Received: from peter by 131.227.8.61 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Jan 2012 11:30:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 58 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 131.227.8.61 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:AYmKHN81P2LC7Keg7CIAijT9yEg= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:13655 Archived-At: Andy Wingo writes: > On Mon 23 Jan 2012 22:03, Mark H Weaver writes: >> 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. > > I know I'm going to sound like Mr. Collins in Pride and Prejudice here, > but I flatter myself that I know a thing or two about managing change -- > I mean, replacing the lazy-memoizing evaluator with the compiler, > retrofitting psyntax into Guile, the whole subr mess, etc. There is > always room to improve, of course, as in all human endeavor, but for now > it does seem that Guile is getting more powerful _and_ more limpid over > time. > > But frankly though, regarding change, while we do need the freedom to > modify some things, some other practical freedoms just don't make the > cost/benefit cut, for me. For example, considering replacing psyntax, > which seems to be in the back of your mind here. This conservatism is > preventing Guile from adding features. And we do need features -- > local-eval and syntax-parse among them. I'm sorry to say it, Andy, but I'm pretty certain that Mark's correct in this case. When you're making additions to a body of code that's expected to be very widely used in a very diverse variety of applications (such as, for example, the Linux kernel, or glibc), one must be *incredibly careful* not to expose implementation details, because users *will* depend on them and complain bitterly when they are changed or removed. I don't feel that your approach to this issue is consistent with your wishes to massively increase Guile usage during 2012. It seems pretty clear to me that the only (debatable) downside to using Mark's implementation is that some definitions end up in the "wrong" module, while your implementation has several potentially *major* problems (including the necessity of providing universally unique gensyms) which Mark has managed to avoid. I am at a loss to understand why you are so vehemently opposed to using Mark's approach (even if only in the short term while you two find a mutually-agreeable solution), and I urge you to reconsider. This is just my £0.02, and as "mere user" of Guile my opinion is probably of little value in this discussion. And as Mark pointed out, you've clearly made your decision on this; I'm not holding much hope of changing your mind. Thanks for all your continuing work on Guile. Regards, Peter -- Peter Brett Remote Sensing Research Group Surrey Space Centre