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 21:11:51 -0500 Message-ID: <878vkxsvbs.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1327371178 15071 80.91.229.12 (24 Jan 2012 02:12:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 Jan 2012 02:12:58 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jan 24 03:12:54 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 1RpVsS-0007kV-UY for guile-devel@m.gmane.org; Tue, 24 Jan 2012 03:12:53 +0100 Original-Received: from localhost ([::1]:55984 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpVsS-0001BJ-1B for guile-devel@m.gmane.org; Mon, 23 Jan 2012 21:12:52 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:59497) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpVsP-0001B3-5p for guile-devel@gnu.org; Mon, 23 Jan 2012 21:12:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpVsN-0003GO-Dd for guile-devel@gnu.org; Mon, 23 Jan 2012 21:12:49 -0500 Original-Received: from world.peace.net ([96.39.62.75]:34265) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpVsN-0003GB-7Q for guile-devel@gnu.org; Mon, 23 Jan 2012 21:12:47 -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 1RpVsG-0002Wu-L7; Mon, 23 Jan 2012 21:12:40 -0500 In-Reply-To: <87zkdem58t.fsf@pobox.com> (Andy Wingo's message of "Mon, 23 Jan 2012 23:19:30 +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:13652 Archived-At: Andy Wingo 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. These are certainly impressive accomplishments, and I salute you for this excellent work! :) However, these accomplishments do not demonstrate that you understand the importance of hiding implementation details so that future Guile hackers can make similar transformations a decade or two from now. For example, you seem unabashedly content to lock us into using psyntax forever, despite the fact that it has known deficiencies having to do with its phase story, as well as limitations in its handling of hygiene in complex macros. (c.f. "Improved hygiene", SRFI 72). I don't mean to suggest that we should replace psyntax anytime soon, but we might want to replace it in a decade or two. Therefore, it concerns me when I see internal psyntax representations exported in our API. > 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. I agree that sometimes practical necessity outweighs the need to hide implementation details. However, in this case, the only "benefit" is to satisfy your desire to keep `the-environment' out of psyntax. > This conservatism is preventing Guile from adding features. And we do > need features -- local-eval and syntax-parse among them. For the record, I absolutely want Stefan to have what he needs to implement `syntax-parse'. My understanding is that all he needs is a way to associate properties with syntactic keywords. Toward that end, I proposed that we should add something analogous to procedure properties for macros. This can be done without exposing internal details as you have done. > But what if they're the wrong interface? > > Well, then we use the normal deprecation mechanism to get rid of them, > eventually (in the 2.2 series, for example). We learned something. > Users get warned off the code. Life goes on. Yes, this is always an option, but it is a _painful_ option for all involved. If we can already foresee the need to deprecate an interface, wouldn't it be better not to add it in the first place? * * * * * Anyway, I can plainly see that your mind is set on this, and that all of the above words were a waste of effort, so I'm going to try to drop it. I just have one final request: please at least change the lexical environments in your `local-eval' implementation to use the future-proof `evaluator procedure' representation, as I have done in mine. FWIW, criticisms aside, I _do_ very much appreciate that you heard my plea for local-eval in 2.0.4, and that you have put so much time into this. Thanks for that, and for all the wonderful things you have done for Guile and GNU. Mark