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: summary: lilypond, lambda, and local-eval Date: Sun, 18 Dec 2011 12:27:42 +0100 Message-ID: <87vcperufl.fsf@pobox.com> References: <87r506uodd.fsf@pobox.com> <87pqfpj7e3.fsf@netris.org> <87aa6skika.fsf@netris.org> <878vmaicb6.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 1324207680 28675 80.91.229.12 (18 Dec 2011 11:28:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 18 Dec 2011 11:28:00 +0000 (UTC) Cc: guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Dec 18 12:27:55 2011 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 1RcEuH-00080e-4h for guile-devel@m.gmane.org; Sun, 18 Dec 2011 12:27:53 +0100 Original-Received: from localhost ([::1]:41499 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcEuG-00053Q-He for guile-devel@m.gmane.org; Sun, 18 Dec 2011 06:27:52 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:47866) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcEuC-000539-V6 for guile-devel@gnu.org; Sun, 18 Dec 2011 06:27:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RcEuB-00022B-Ga for guile-devel@gnu.org; Sun, 18 Dec 2011 06:27:48 -0500 Original-Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62]:51277 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcEuB-000225-DU for guile-devel@gnu.org; Sun, 18 Dec 2011 06:27:47 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 6C788705F; Sun, 18 Dec 2011 06:27:46 -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=MYHR2bGZivP7nO9CeYlVXBCRVq0=; b=ElD7hj 2EX0X8xW6xhLiWEmZxMDMqIzmTMP5zpjs4LkzJIQXZAIR1xqsZ9unMk6s4Aaahna yvGKuGwHAcNARKaNLyTnY1Cvx4XHXvcztkIQU2gl0EovV5K8EAxd0vnhjyLiOjYJ p7vwmXMEZ3a7SYiqIgGgWaGPLXXraWlOS3SMM= 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=jDexrkL5eBe+k38/s5YeF3Jw998jpBYY GhBvza52DATXETK/oWL+d4mUqYqsjvW4XP7aaTpX7HGD5rSuIqdUQbxhF6WhSK1p RkHyJLjOe8m+rFmNbuFAlKrE9ZgNDb/AGosrmU1ajwpIpwtYyJiVOuP39NjlDyNP yIsgEPy3gtA= 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 65C4B705E; Sun, 18 Dec 2011 06:27:46 -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 A92F4705D; Sun, 18 Dec 2011 06:27:45 -0500 (EST) In-Reply-To: <878vmaicb6.fsf@netris.org> (Mark H. Weaver's message of "Sun, 18 Dec 2011 02:11:41 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-Pobox-Relay-ID: 4ED169B8-296B-11E1-98BA-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:13152 Archived-At: On Sun 18 Dec 2011 08:11, Mark H Weaver writes: > So, it turns out that the best place to transform (the-environment) into > standard scheme code is in the macro expander itself. Are you certain that it is desirable to transform it into standard Scheme code? The statement that the-environment acts "as if it were the expression, (case-lambda ....)" doesn't mean that you have to implement it that way. > Indeed, only the macro expander has enough information to generate an > optimal list of "reachable lexicals", i.e. lexical variables that are > accessible using normal symbols (as opposed to syntax objects) [more > on this below]. Are you certain that you want to restrict the set of identifiers? To me it sounds like an optimization, perhaps premature. What do you think about having a tree-il form have a field for the names and a field for the gensyms of captured lexicals? > This is great news, because it means that `the-environment' will no > longer require its own tree-il type, and the compiler will only see the > standard scheme code that it expands into. > > However, we will need a robust way to either (A) specify, (B) discover, > or (C) predict the order of the captured lexicals in a closure. We could compile `the-environment' so that at runtime it yields a record containing a vector of syntax objects and a vector of corresponding variable objects. (When the compiler boxes a variable, it does so in a variable object, as from make-variable.) Then you don't introduce cross-cutting assumptions to the compiler and runtime. > I have yet to decide which option to take. Suggestions welcome. WDYT about mine? :) > There's also another issue that has come to my attention. If we must > support arbitrary syntax-objects to be passed to `local-eval', in many > (most?) cases this will greatly increase the number of lexicals that > must be captured, and thus boxed, by (the-environment). If a tree-il `the-environment' form takes a list of names and gensyms, then we can provide the possibility in the future to limit the set of captured bindings. > So, I'm thinking that (the-environment) should only capture lexical > variables that are reachable using normal symbols. I think I disagree here. It is strictly less useful to capture a subset of bindings, and it would only be done for efficiency, and it probably doesn't matter. So yeah, I guess my arguments here depend on a tree-il the-environment form. I wonder if that is the right thing, though; maybe there is a lower-level concept at work. The only thing that you need that tree-il doesn't give you right now is the ability to declare a variable as boxed, and to capture its identity. Maybe what we need is a form that evaluates to the variable corresponding to a bound lexical. Then `the-environment' could expand out to (make-struct/no-tail '(name ...) (list (capture-lexical name) ...)) You would still need support from the expander to get the set of currently-bound names, but maybe that is a new primitive that we could add. Could we do it all with two new low-level primitives? And then, could we actually put `the-environment', environment accessors, and everything else into a module? Andy -- http://wingolog.org/