From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.lisp.guile.bugs Subject: bug#10132: Help lilypond interleave scheme and lilypond code in guile 2.x Date: Fri, 25 Nov 2011 14:35:28 +0100 Message-ID: <871uswqq8v.fsf@fencepost.gnu.org> References: <87vcq8bghp.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1322228208 32575 80.91.229.12 (25 Nov 2011 13:36:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 25 Nov 2011 13:36:48 +0000 (UTC) Cc: ian@hulin.org.uk, 10132@debbugs.gnu.org To: Andy Wingo Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Fri Nov 25 14:36:43 2011 Return-path: Envelope-to: guile-bugs@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 1RTvxI-0000TO-QM for guile-bugs@m.gmane.org; Fri, 25 Nov 2011 14:36:41 +0100 Original-Received: from localhost ([::1]:49239 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTvxI-00075I-DF for guile-bugs@m.gmane.org; Fri, 25 Nov 2011 08:36:40 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:38789) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTvxC-000717-RJ for bug-guile@gnu.org; Fri, 25 Nov 2011 08:36:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RTvx3-0007jk-5u for bug-guile@gnu.org; Fri, 25 Nov 2011 08:36:34 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36620) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTvx3-0007jg-4N for bug-guile@gnu.org; Fri, 25 Nov 2011 08:36:25 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RTvyb-0007eb-SC for bug-guile@gnu.org; Fri, 25 Nov 2011 08:38:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: David Kastrup Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Fri, 25 Nov 2011 13:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10132 X-GNU-PR-Package: guile X-GNU-PR-Keywords: X-Debbugs-Original-Cc: bug-guile , Ian Hulin Original-Received: via spool by submit@debbugs.gnu.org id=B.132222826929403 (code B ref -1); Fri, 25 Nov 2011 13:38:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 25 Nov 2011 13:37:49 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RTvyO-0007eB-Kv for submit@debbugs.gnu.org; Fri, 25 Nov 2011 08:37:49 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RTvyM-0007e5-SP for submit@debbugs.gnu.org; Fri, 25 Nov 2011 08:37:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RTvwj-0007iH-OH for submit@debbugs.gnu.org; Fri, 25 Nov 2011 08:36:10 -0500 Original-Received: from lists.gnu.org ([140.186.70.17]:33091) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTvwj-0007iB-IM for submit@debbugs.gnu.org; Fri, 25 Nov 2011 08:36:05 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:38755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTvwi-0006wG-8o for bug-guile@gnu.org; Fri, 25 Nov 2011 08:36:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RTvwc-0007hJ-2H for bug-guile@gnu.org; Fri, 25 Nov 2011 08:36:04 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:58824) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTvwb-0007hF-VF for bug-guile@gnu.org; Fri, 25 Nov 2011 08:35:58 -0500 Original-Received: from localhost ([127.0.0.1]:55108 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTvwa-0002vJ-7B; Fri, 25 Nov 2011 08:35:56 -0500 Original-Received: by lola (Postfix, from userid 1000) id 42BDCE050C; Fri, 25 Nov 2011 14:35:28 +0100 (CET) In-Reply-To: <87vcq8bghp.fsf@pobox.com> (Andy Wingo's message of "Fri, 25 Nov 2011 12:15:14 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 25 Nov 2011 08:38:01 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:5947 Archived-At: Andy Wingo writes: > Hi David, > > This bug was forked from bug 10099, where David has a longer > explanation. > > On Fri 25 Nov 2011 11:37, David Kastrup writes: > >> So much for that. The next quote is for a totally different issue, the >> availability of local environments and evaluation in them. Lilypond has >> an input syntax of its own, and it allows interspersing Scheme code. $ >> or # switches to the Scheme interpreter (for one sexp) when in Lilypond >> syntax, and #{ ... #} switches to Lilypond inside. > > Aaah. Thanks for this explanation; I had never seen this code before. > > Do you use a read-hash-extend reader for #{#} ? Yes: This link is likely a bit of a moving target since I have several patches in the queue to make the behavior more predictable (and produce better quality error messages when things go wrong). > What do you use to parse the lilypond code? What does it parse to? Classical Bison/Flex parser/scanner. There is no "what does it parse to" since the Bison rules execute the actions on the fly: it is a classical interpreter. With a number of lexical and semantical tie-ins, it would be non-trivial to actually create an intermediate representation. The file responsible for reading and evaluating embedded Scheme expressions is The proposed robustifying changes currently in the queue are in . The reading is done by the lexer. Evaluation of $ forms is done in the lexer, evaluation of # forms is delayed and happens in the parser in order to avoid timing problems (lookahead tokens should preferably not be evaluated while they are still lookahead since they might depend on the actions of the commands before them). > I agree that the-environment and local-eval were nice solutions for > this. In Guile 2.0 it's not as nice for you, because if you implement > another evaluator, you don't get backtraces that are as nice. We don't really do anything in the line of backtraces. Until the proposed patch gets through, we don't really do anything sensible in the line of error messages either. >> As I said: for this particular application, I have coded a rather >> inelegant and resource-grabbing workaround that really is not going >> to help performance since the intertwined Lilypond interpreter does >> not benefit from precompilation of mostly trivial lambda functions >> when the actual procedure-environment is unlikely to ever reference >> more than five variables. > > Understood. Let's work to find a good solution in 2.0. If you follow the history of parser-ly-from-scheme.scm, you'll see that there has been a flurry of activity recently. Before I had to cater for GuileV2, the code just sweeped up the procedure-environment of a basically empty lambda function and left all rereading and evaluation to runtime. Even earlier than that, there was a complicated interpretation of # and $ where the respective expressions were all evaluated in a let-form at runtime before the Lilypond parser went to work. The current approach of wrapping everything in lambda as compared to the historic implementation of evaluating everything Scheme before starting the Lilypond interpreter has the advantage that the timing of evaluation (if any) is determined by the Lilypond interpreter. The procedure-environment approach was elegant and minimally complex. The question is how feasible it is for the Guile compiler to capture an environment in a form that can be used even after compilation. Like taking the address of a variable in C, the export of such an environment interferes with a number of static optimizations. For our particular application, readonly access to the symbols in the environment should be quite sufficient, but of course I can't vouch for other potential uses. -- David Kastrup