[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10132: Help lilypond interleave scheme and lilypond code in guile 2.
From: |
Andy Wingo |
Subject: |
bug#10132: Help lilypond interleave scheme and lilypond code in guile 2.x |
Date: |
Fri, 25 Nov 2011 15:26:00 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) |
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 <address@hidden> 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/