GNU bug report logs - #10132
Help lilypond interleave scheme and lilypond code in guile 2.x

Previous Next

Full log

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: David Kastrup <dak <at> gnu.org>
Cc: bug-guile <bug-guile <at> gnu.org>, Ian Hulin <ian <at> hulin.org.uk>
Subject: Re: Help lilypond interleave scheme and lilypond code in guile 2.x
Date: Fri, 25 Nov 2011 15:26:00 +0100

Hi,

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 <dak <at> gnu.org> 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.

> 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.  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.

Cheers,

Andy
-- 
http://wingolog.org/

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.