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 15:44:27 +0100 Message-ID: <87sjlcp8hg.fsf@fencepost.gnu.org> References: <87vcq8bghp.fsf@pobox.com> <871uswqq8v.fsf@fencepost.gnu.org> <87lir4b7nr.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1322232336 29388 80.91.229.12 (25 Nov 2011 14:45:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 25 Nov 2011 14:45:36 +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 15:45:31 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 1RTx1u-0005I0-Ki for guile-bugs@m.gmane.org; Fri, 25 Nov 2011 15:45:30 +0100 Original-Received: from localhost ([::1]:40150 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTx1u-0007v0-3C for guile-bugs@m.gmane.org; Fri, 25 Nov 2011 09:45:30 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:53849) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTx1r-0007tJ-7e for bug-guile@gnu.org; Fri, 25 Nov 2011 09:45:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RTx1o-0005sx-UD for bug-guile@gnu.org; Fri, 25 Nov 2011 09:45:27 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTx1o-0005se-Sc for bug-guile@gnu.org; Fri, 25 Nov 2011 09:45:24 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RTx3N-0000oM-K2 for bug-guile@gnu.org; Fri, 25 Nov 2011 09:47: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 14:47: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.13222323733061 (code B ref -1); Fri, 25 Nov 2011 14:47:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 25 Nov 2011 14:46:13 +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 1RTx2b-0000nK-EX for submit@debbugs.gnu.org; Fri, 25 Nov 2011 09:46:13 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RTx2Z-0000nC-6M for submit@debbugs.gnu.org; Fri, 25 Nov 2011 09:46:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RTx0y-0005if-VD for submit@debbugs.gnu.org; Fri, 25 Nov 2011 09:44:34 -0500 Original-Received: from lists.gnu.org ([140.186.70.17]:38774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTx0y-0005ia-Ti for submit@debbugs.gnu.org; Fri, 25 Nov 2011 09:44:32 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:53595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTx0x-0007iy-Re for bug-guile@gnu.org; Fri, 25 Nov 2011 09:44:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RTx0w-0005iE-As for bug-guile@gnu.org; Fri, 25 Nov 2011 09:44:31 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:57046) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTx0w-0005i1-16 for bug-guile@gnu.org; Fri, 25 Nov 2011 09:44:30 -0500 Original-Received: from localhost ([127.0.0.1]:50489 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTx0u-0007Ip-J4; Fri, 25 Nov 2011 09:44:29 -0500 Original-Received: by lola (Postfix, from userid 1000) id E2072E050C; Fri, 25 Nov 2011 15:44:27 +0100 (CET) In-Reply-To: <87lir4b7nr.fsf@pobox.com> (Andy Wingo's message of "Fri, 25 Nov 2011 15:26:00 +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 09:47: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:5949 Archived-At: Andy Wingo writes: > I am going to be away from the machine for the weekend, but before I > headed out, I just wanted to put out one idea: > > On Fri 25 Nov 2011 14:35, David Kastrup writes: > >>> 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. > > Have you considered using silex or some other tokenizer in scheme, > combined with the lalr parser from (system base lalr)? See "LALR(1) > Parsing" in the manual for Guile 2.0. Lilypond is not yet capable of running under Guile 2.0 (and needs to stay 1.8-compatible for a considerable time span), so it makes no sense to think about using 2.0 features for core parts of it. The core of Lilypond is quite C++-centric. Parsing takes a non-negligible amount of runtime already. Switching to a different system likely to be slower and less directly interfacing with C++ is not going to be on the agenda anytime soon, and I am less than convinced that this total change of playground would actually make a qualitative difference regarding the implementation of this particular scoping task. >> 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. > > If this is the answer, then we can figure out a way to implement it in > Guile 2.0.x as well. "Readonly access" in this context does not mean "separate copies" but rather "access to the original variables without the need to change them via this access path". If such a closure variable is changed by a function "properly" compiled in the lexical closure (rather than artificially relying on process-environment), we would likely still need to see this change. > But if you are amenable to it, implementing the parser in Scheme would > be another attractive option -- though, it would be a change, and that > has costs. That's not on the table right now in my opinion, and I actually don't see that it would help to a relevant degree since, as I said, lexical and semantic tie-ins require the parser to work _progressively_ instead of being able to compile an intermediate Scheme representation, and without an intermediate representation, I don't see how we could exploit the "natural" implicit implementation of closures in the Scheme compiler. -- David Kastrup