From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Hans Aberg Newsgroups: gmane.lisp.guile.devel Subject: Re: summary: lilypond, lambda, and local-eval Date: Thu, 15 Dec 2011 18:52:35 +0100 Message-ID: <9015E9C4-44FC-4786-83DC-61E90A5F0586@telia.com> References: <87r506uodd.fsf@pobox.com> <9365BFAA-2F16-438E-A6B7-7C2AE4E48B08@telia.com> <87bor9694v.fsf@fencepost.gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1323971578 22723 80.91.229.12 (15 Dec 2011 17:52:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 15 Dec 2011 17:52:58 +0000 (UTC) Cc: guile-devel@gnu.org To: David Kastrup Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Dec 15 18:52:54 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 1RbFUB-0004QX-3B for guile-devel@m.gmane.org; Thu, 15 Dec 2011 18:52:51 +0100 Original-Received: from localhost ([::1]:45594 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbFUA-0007lV-Hr for guile-devel@m.gmane.org; Thu, 15 Dec 2011 12:52:50 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:34070) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbFU5-0007kv-V4 for guile-devel@gnu.org; Thu, 15 Dec 2011 12:52:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbFU4-000256-V8 for guile-devel@gnu.org; Thu, 15 Dec 2011 12:52:45 -0500 Original-Received: from smtp-out21.han.skanova.net ([195.67.226.208]:49251) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbFTy-00023G-8g; Thu, 15 Dec 2011 12:52:38 -0500 Original-Received: from [10.0.1.2] (217.210.127.13) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u26619196) id 4EC0B93A00D001A2; Thu, 15 Dec 2011 18:52:35 +0100 In-Reply-To: <87bor9694v.fsf@fencepost.gnu.org> X-Mailer: Apple Mail (2.1251.1) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 195.67.226.208 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:13119 Archived-At: On 15 Dec 2011, at 18:24, David Kastrup wrote: >>> The "delayed evaluation" thread is a bit long and confusing, so I = would >>> like to try to summarize it. >>>=20 >>> Lilypond has a way to embed Lilypond code in Scheme, and Scheme code = in >>> Lilypond code. The former uses a reader macro, #{#}. The latter = uses >>> specially-marked variables and expressions, specifically, those = preceded >>> by $ or #. >> ... >>> It took some time for everyone to understand the problem. In the = end, >>> there were four workable possibilities. >>>=20 >>> 1) Keep using closures. >>=20 >> When doing a parser on top of Guile, I noticed one must first build = an >> unevaluated closure, and only thereafter call the evaluator. Scheme >> has some restrictions forcing this, for example, the lambda cannot >> appear as a free symbol, though it is possible in Guile using >> scm_sym_lambda. >>=20 >> It might be useful with a variation of scm_eval_string() that only >> parses and builds the closure, but not calls the evaluator. >=20 > I am not sure what you mean with "closure" here, but just "read" = parses > a form. I build them from scratch, using the scm_x calls, with a parser. This = way, it is possible to a more than within the Scheme paradigm itself. = For example, scm_list_x(scm_sym_lambda, ...) gives an unevaluated lambda-expression. Some symbols are not available = in Guile, so for example, I have in my init(): SCM list_ =3D scm_from_locale_symbol("list"); After an expression has been built, the parser calls = scm_primitive_eval(). However, suppose one wants to insert some Scheme = code in to the expression, then scm_eval_string() will call the = evaluator, enforcing that only complete Scheme expressions can be = inserted: Without that restriction it would be possible to have an expression like f :=3D x |-> scheme "(+ x 1)" where only the quote is the actual scheme code and the other handled by = the external parser, and where the external "x" binds to the one in the = Scheme code string "(+ x 1)". However, when scm_eval_string() calls the = evaluator, one gets an error, because "x" is not bound. Hans