From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.lisp.guile.devel Subject: Re: summary: lilypond, lambda, and local-eval Date: Thu, 15 Dec 2011 15:46:15 +0100 Organization: Organization?!? Message-ID: <87aa6t7v0o.fsf@fencepost.gnu.org> References: <87r506uodd.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1323960415 31898 80.91.229.12 (15 Dec 2011 14:46:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 15 Dec 2011 14:46:55 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Dec 15 15:46:51 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 1RbCa8-0001uP-RU for guile-devel@m.gmane.org; Thu, 15 Dec 2011 15:46:49 +0100 Original-Received: from localhost ([::1]:58835 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbCa5-0002Zh-E3 for guile-devel@m.gmane.org; Thu, 15 Dec 2011 09:46:45 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:33744) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbCZx-0002Je-Mr for guile-devel@gnu.org; Thu, 15 Dec 2011 09:46:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbCZr-00050b-N5 for guile-devel@gnu.org; Thu, 15 Dec 2011 09:46:37 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:44167) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbCZr-00050M-Dl for guile-devel@gnu.org; Thu, 15 Dec 2011 09:46:31 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RbCZp-0001hG-00 for guile-devel@gnu.org; Thu, 15 Dec 2011 15:46:29 +0100 Original-Received: from p508eb977.dip.t-dialin.net ([80.142.185.119]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Dec 2011 15:46:28 +0100 Original-Received: from dak by p508eb977.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Dec 2011 15:46:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 61 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: p508eb977.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) Cancel-Lock: sha1:eTl2G5mwQuU8sCdfq4FMqIgQsFQ= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:13111 Archived-At: Andy Wingo writes: > It took some time for everyone to understand the problem. In the end, > there were four workable possibilities. > > 1) Keep using closures. > > 2) Incorporate local-eval and the-environment into Guile 2.0. > > 3) Have lilypond use its own evaluator or compiler. > > 4) Have lilypond make the embedded lilypond code expand out to actual > Scheme. (It was unclear whether the lilypond grammar allowed > this.) It is pretty clear that the Lilypond grammar will not allow this. It has ambiguities that can only be resolved at runtime and impact both the parse tree as well as the tokenizing process. > Mark and Noah looked at implementing local-eval, and I recommended > staying with the closure solution. Ludovic noted success with method > (3) in the Skribilo context. Mark basically showed a sketch that worked by switching off the compiler of the current top form when the-environment got used. With LilyPond, my basic statement was that performance of the Scheme part was a non-issue when compared against the Lilypond parts. As an afterthought, this may not be totally correct: if you have code of the kind (define-music-function ... (x y z) (do a complex calculation purely in Scheme) (return results using #{ ... #})) then the speed of the "calculation" can conceivably govern the runtime after all, so switching off all compilations in the enclosing top form might have runtime effects not masked by the costs of #{ ... #}. It is, however, untypical to have costly calculations in the front end of Lilypond. The runtime is usually spent elsewhere, mostly in C++ code. > I would like to start a new thread around local-eval, but besides > that, we should probably agree on the summary first. So please do > send any corrections to this summary to the list. Thanks :) A note to point 4) if LilyPond were a language for which expansion to Scheme would be feasible, compilation of the whole nested constructs would have to happen in one humongous piece since there is no other way to share lexical environments. And a note to point 1) the Scheme compiler is more likely to complain about (lambda () arbitrary-garbage-sexp) than the interpreter when the preliminary closure-building step picks up line noise from inside of Lilypond comments or strings. In comparison to the previous code version running under Guile 1.8, robustness, cleanliness and manageability of the code have taken a step backwards. It's not a mile, but not trivial either. -- David Kastrup