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: local-eval on syntax-local-binding, bound-identifiers Date: Tue, 17 Jan 2012 00:27:07 +0100 Message-ID: <8739bfi5ys.fsf@pobox.com> References: <87sjjg7gqm.fsf@pobox.com> <87zkdo2ukg.fsf@netris.org> <87r4yzj4gu.fsf@pobox.com> <8762gb3hfv.fsf@netris.org> <87ipkbisna.fsf@pobox.com> <87wr8r1j1q.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 1326756442 17374 80.91.229.12 (16 Jan 2012 23:27:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 16 Jan 2012 23:27:22 +0000 (UTC) Cc: guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jan 17 00:27:18 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 1RmvxN-0004rV-7l for guile-devel@m.gmane.org; Tue, 17 Jan 2012 00:27:17 +0100 Original-Received: from localhost ([::1]:51284 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmvxM-0004Ti-Lc for guile-devel@m.gmane.org; Mon, 16 Jan 2012 18:27:16 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:34478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmvxJ-0004Td-Sj for guile-devel@gnu.org; Mon, 16 Jan 2012 18:27:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RmvxI-0005z4-AF for guile-devel@gnu.org; Mon, 16 Jan 2012 18:27:13 -0500 Original-Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62]:51507 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmvxI-0005z0-3T for guile-devel@gnu.org; Mon, 16 Jan 2012 18:27:12 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 5A74083FB; Mon, 16 Jan 2012 18:27:11 -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=hzefBKzuIrLNwX+8niaUtsSf5oc=; b=QNo8PL dHkOw+O8G1xZreZQdCYqlae7FiugXWBhy7rV92j96PJJEjD+CoZHFvTtFB/gbFIF KQvRTLknDQWReVlZu7W2e2yD/sVcSDLBvCmVX7zy0N/HzBfRiuz4xRDBXrEXu+8g zbdXq+PNlZgjWjNuqTAwLLrhSg1QdswcbwB/o= 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=oO5Vq9Jm4VMdQxzrjJLGRyPyjO4QTlax 2Y80Xb0g7Dy7Akt/OFP3+kj0GFOHBcWuU3WXmU8xUnXZs00sTaHuzf6rXht0xO5g M3NnEpmYAKqfcD85bgxhpVWUfR3w80xAMQOhpRW1KXEuupdw80ynwdECdIhEUDtS Trgmq8siMr4= 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 5297583FA; Mon, 16 Jan 2012 18:27:11 -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 84FA183F9; Mon, 16 Jan 2012 18:27:10 -0500 (EST) In-Reply-To: <87wr8r1j1q.fsf@netris.org> (Mark H. Weaver's message of "Mon, 16 Jan 2012 15:36:33 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-Pobox-Relay-ID: 9D0DC9CE-4099-11E1-AC44-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:13550 Archived-At: Hi Mark, On Mon 16 Jan 2012 21:36, Mark H Weaver writes: > Thanks again for working on this. And thank you again for all your work, and patience with my pigheadedness. > if you insist in this foolish quest to banish `the-environment' to > sleep in the shed as a second-class citizen, I cannot stop you :) TBH I think this is the best thing we can do for local-eval. We preserve flexibility for local-eval, make other experiments possible, and the local-eval implementation is a bit more perspicacious, as the scoping is more lexical (in the same file, even). I know there's a smilie in your statement, but really, it's not just local-eval: there's loads more that should be broken out into modules over time, somehow :) Think of it as building a hippie commune of functionality, instead of making everyone live in the same house :) (OK, that's stretching it a bit, but perhaps it is partially apt?) Now, specific commentary. > How about something like (bound-identifiers #'here)? scheme@(guile-user)> (bound-identifiers #'here) $5 = () scheme@(guile-user)> (let ((x 10)) (bound-identifiers #'here)) $6 = (#(syntax-object x ((#f top) shift #(ribcage #(x) #((top)) #("i176"))) (hygiene guile-user))) What should the answer be in this case? Would you expect `x' in the list? Certainly for the-environment you would. But here: scheme@(guile-user)> (define-syntax bound-here (lambda (x) (with-syntax (((id ...) (map (lambda (id) (datum->syntax x id)) (bound-identifiers #'here)))) #'(list 'id ...)))) scheme@(guile-user)> bound-here $7 = (#(syntax-object x ((#f top) shift #(ribcage #(x) #((top)) #("i192"))) (hygiene guile-user))) scheme@(guile-user)> (let ((y 10)) bound-here) $8 = (#(syntax-object x ((#f top) shift #(ribcage #(x) #((top)) #("i192"))) (hygiene guile-user))) So, it seems to be sensible. Now, what to do with these identifiers: you if you introduce one into another macro, the mark will indeed be stripped. I'm not sure what else you can do with a syntax-object, actually! Pass it directly to eval or compile, I guess, and in that case we do lose, as the anti-mark isn't stripped. But that's the case for other syntax objects captured in a syntax transformer, as well. Should we anti-mark only within the dynamic extent of a transformer, I wonder? > As I've already said, I don't think `bound-identifiers' will be useful > in a full implementation of `local-eval', so once we move to that > improved implementation, `bound-identifiers' will be left around as an > orphan: a primitive of dubious value, introduced specifically to > implement something that it turned out to be insufficient for. Hummmmm. Definitely something to think about. What if instead we implemented closure serialization somehow? Then we would handle procedural macros too, and bound-identifiers would still be sufficient. Maybe that idea is a little too crazy. If we have to lexical contours associated with bindings, recursive is only one bit: you probably also need letrec vs letrec*. >> To be perfectly honest, this stuff is very confusing to me, but I think >> I can see how this can happen, yes. >> >> I do think that it's important to fix this bug at some point, but IMO it >> is not a blocker for local-eval, much less 2.0.4. > > I strongly disagree. Your implementation will clearly be buggy without > a proper solution to the collision of gensyms (labels and marks, at > least). I don't know about you, but personally I prefer rock-solid code > with clearly documented limitations (that almost no one is likely to hit > anyway) to buggy code. > > If you don't want to deal with the gensym problem for 2.0.4, there's an > easy solution. Simply strip the wraps for now (as is done by my patch), > and everything will robust as long as we don't capture local syntax. Thinking about it a little more, labels are a non-issue. All they need to be is unique in the sense of eq?. Labels are strings. If they are loaded in separate compilation units, they will be unique, no matter what their contents. Labels are more important than marks, also, for the correctness of the algorithm. A mark collision is only an issue if there is also a symbolic collision. Label collision could alias completely unrelated bindings. Anyway, I would rather serialize bad marks than no marks. That's my personal opinion ;-) But if you think this is a huge issue, let's fix the marks to be more unique, no? Note that there is a well-known optimization that you don't actually need to generate the characters corresponding to a gensym until they are needed. It might serve your purposes. OK, I'm getting very sleepy now :) Let me know your thoughts. It would be great if all of this could land before Sunday. Though the cricket folk say "pace is nothing without guile", Guile is nothing without a good development pace ;-) Cheers, Andy -- http://wingolog.org/