From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: syntax-local-binding Date: Mon, 23 Jan 2012 23:19:30 +0100 Message-ID: <87zkdem58t.fsf@pobox.com> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1327357190 26751 80.91.229.12 (23 Jan 2012 22:19:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 Jan 2012 22:19:50 +0000 (UTC) Cc: guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jan 23 23:19:44 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 1RpSEp-0006sY-QR for guile-devel@m.gmane.org; Mon, 23 Jan 2012 23:19:44 +0100 Original-Received: from localhost ([::1]:50712 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpSEo-0003c5-La for guile-devel@m.gmane.org; Mon, 23 Jan 2012 17:19:42 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:59536) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpSEk-0003bp-Hw for guile-devel@gnu.org; Mon, 23 Jan 2012 17:19:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpSEi-0000uy-ES for guile-devel@gnu.org; Mon, 23 Jan 2012 17:19:38 -0500 Original-Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62]:56917 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpSEi-0000us-9k for guile-devel@gnu.org; Mon, 23 Jan 2012 17:19:36 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id A7AEE8ABD; Mon, 23 Jan 2012 17:19:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=cLEjYFi7RBMBwExJY5fPrDIsjHE=; b=PvW2M+ o+ibgGUlaHtS9kgyMnV/GJPOEnzRq/+PPme7w9fpkIvP/QO8JFzxJXpof0jwdIQv beZoPSxqNFufu/A+kQIs5m2Z4S0nWFAuAfhS9AU+6vY3A9Yr7vDUKCdTWf7Oclya 0Y8ch3Q4EBXmD6O21JtyAZ9tc8x2AbALYAS+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=tjoKKNj9aWehyF/2eRIPQ2VR80VeR6eH biAjX16cpv1cAQNCRYusOa70MY1f31/IEKGQjIMsB54enGiiKNMnrfhApSXa7HEF LwpSz+eq9oXOPmACJsH5Ce/hu2Yiq/SjYGBpGxDAAPeqKhWU92iqG3b/umBCeXnh Zl6B91mMB9k= Original-Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 9EF0B8ABC; Mon, 23 Jan 2012 17:19:35 -0500 (EST) Original-Received: from badger (unknown [90.164.198.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id BD5A58ABA; Mon, 23 Jan 2012 17:19:34 -0500 (EST) In-Reply-To: <87hazmrv15.fsf@netris.org> (Mark H. Weaver's message of "Mon, 23 Jan 2012 16:03:34 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-Pobox-Relay-ID: 5484C3E8-4610-11E1-BE92-65B1DE995924-02397024!a-pb-sasl-sd.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 74.115.168.62 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:13651 Archived-At: Hi Mark, On Mon 23 Jan 2012 22:03, Mark H Weaver writes: > Andy Wingo writes: > >> 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. I'm not sure we're talking about the same thing here; do see Alex Shinn's NAK on R6RS: http://www.r6rs.org/ratification/results.html#X70 While I disagree with his assessment of the identifier-syntax tradeoff, I think he correctly identifies it as a tradeoff. >>>> 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. 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. > 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. Apart from the fact with `the-environment' in psyntax, it's in the default environment, of course; though with autoloads one can get around that... With `the-environment' in a module, in 2.0.4 we could have three functions added to psyntax: syntax-local-binding, syntax-locally-bound-identifiers, and syntax-module. The first and the third have precedent in Racket (whose hackers have been able to do significantly awesome stuff). The second is strange, but seems OK. I'm OK with them. 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. > 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. Hear, hear. > 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. I really do value your work, and your words, Mark. Besides that personal appreciation, I think you're doing good work for Guile. We happen to disagree here on a matter of implementation. OK. It's a feature we have worked on sufficiently that it should probably make it into 2.0.4. OK. One of us will be unhappy about whatever goes in, it seems. I appreciate the calcification argument, but I simply think that it does not apply in this case. The thing that we shouldn't forget, though, is that regardles of the particular technique, if local-eval goes in, we'll have won already -- local-eval in a modern Scheme. Regards, Andy -- http://wingolog.org/