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: Fri, 16 Dec 2011 10:28:36 +0100 Message-ID: <87liqcamrf.fsf@pobox.com> References: <87r506uodd.fsf@pobox.com> <87pqfpj7e3.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 1324027743 12920 80.91.229.12 (16 Dec 2011 09:29:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2011 09:29:03 +0000 (UTC) Cc: guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Dec 16 10:28:59 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 1RbU66-0001eA-70 for guile-devel@m.gmane.org; Fri, 16 Dec 2011 10:28:58 +0100 Original-Received: from localhost ([::1]:42717 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbU65-0001nj-Ox for guile-devel@m.gmane.org; Fri, 16 Dec 2011 04:28:57 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:60233) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbU5z-0001nJ-2v for guile-devel@gnu.org; Fri, 16 Dec 2011 04:28:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbU5q-0002B1-Ly for guile-devel@gnu.org; Fri, 16 Dec 2011 04:28:51 -0500 Original-Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62]:48139 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbU5q-0002Ah-91 for guile-devel@gnu.org; Fri, 16 Dec 2011 04:28:42 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 00C3064FC; Fri, 16 Dec 2011 04:28:41 -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=KaGqhXVp/+sUnLoHsYrV+lqhgKI=; b=yXUM/j p80R0KA14I6CIvNCyaNb5rGG1jNoUJd6E0QdmVOohqBo0Sf3/RJw/hBSGC5FHzMd Citzfot7/fQ55Q116xIVrEL6Fh9XoYRtTzRKxCcq3RE9IZicIzNaprHuPbhc1pkK BcDzc2oGvmaf7YAYrZVfk5jY81p3pCkhZSz30= 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=erHiEjcXe92QYHKN90ujCLoedTIZPTIv rOXSaDKhvRdJUaMgnv/tVNq0TuXVNcJN51b1Jmsf7pEWqr4P2Yn7Hvt6kw//+z1d YBU/1VGY7g8NNy8UVF2hSfggnRLR3VvMtppBLJdcrF8yj6V3vXk8SeyGI13vk/Pi K4wUR9MUZZk= 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 E750764FB; Fri, 16 Dec 2011 04:28:40 -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 F278864FA; Fri, 16 Dec 2011 04:28:39 -0500 (EST) In-Reply-To: <87pqfpj7e3.fsf@netris.org> (Mark H. Weaver's message of "Fri, 16 Dec 2011 02:35:48 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-Pobox-Relay-ID: 56D26F76-27C8-11E1-B41C-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:13131 Archived-At: Hi Mark, This is an interesting plan. I still have some doubts, but perhaps you can make it work. First, a couple of notes: On Fri 16 Dec 2011 08:35, Mark H Weaver writes: > (quote ) ;; simple list structure > (quote ) ;; simple list structure Perhaps syntax-objects can give you what you need here. > ) ;; XXX not sure how best to represent this The expander needs to serialize representations of modules in syntax objects, and for that purpose it uses the module name. "Anonymous" modules actually have generated names, lazily. Use `module-name'. I like the "modeling the-environment as a scheme expression" approach; it gives `the-environment' some semantics. I used to ignore people who yammered on about semantics and languages, but I have grown to respect that approach to language development. So thank you there. Also, note that forms that `set!' all bound lexicals in the `the-environment' will cause them all to be boxed, so there is no boxed bitvector needed. > How to implement `local-eval' > ============================= > > When `local-eval' is called on a lexical environment that was created by > compiled code, it will do the following: > > * Macroexpand the local expression within . > > * Compile the expanded expression within . > (I'll explain how to do this below) > > * Make a copy of the closure from the lexical environment object, but > replace its code (the dispatcher) with the newly compiled code. > > * Call the newly created closure. We are really far from considering efficiency here :) Would you always use the compiler for this task? (I think I would.) But otherwise, this sounds sensible, with a caveat:: hygiene, nested definitions, and the macro expander. What does local-eval really mean? What are the meanings of these expressions: ;; Toplevel (local-eval '(define foo 42) (the-environment)) ;; Lexical, tail context (local-eval '(define foo 42) (let ((x 100)) (the-environment))) ;; Lexical, tail context -- but with a definition (local-eval '(begin (define foo 42) foo) (let ((x 100)) (the-environment))) ;; Lexical, tail context -- but with a definition, and nested reference (local-eval '(begin (define foo 42) (bar)) (let ((x 100)) (define (bar) foo) (the-environment))) ;; Lexical, not a definition context (local-eval '(define foo 42) (let ((x 100)) not-a-definition (the-environment))) What about this one: ;; Keeping in mind that `or' expands to (let ((t ...)) (if t t ...)), ;; hygienically (local-eval 't '(let ((t 42)) (or #f (the-environment)))) Can you pass syntax objects into `local-eval'? Are let-syntax / letrec-syntax / nested define-syntax forms present in a local environment? Currently these things never leave the expander. I suppose as long as they are understood to be opaque, it would be OK. That's all I really wanted to write about local-eval, I think, so no promised other mail. Thanks for thinking about these things :) Andy -- http://wingolog.org/