--- Begin Message ---
|
Subject: |
Help lilypond interleave scheme and lilypond code in guile 2.x |
|
Date: |
Fri, 25 Nov 2011 12:15:14 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) |
Hi David,
This bug was forked from bug 10099, where David has a longer
explanation.
On Fri 25 Nov 2011 11:37, David Kastrup <address@hidden> 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 #{#} ?
What do you use to parse the lilypond code? What does it parse to?
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.
> 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.
Andy
--
http://wingolog.org/
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#10132: Help lilypond interleave scheme and lilypond code in guile 2.x |
|
Date: |
Fri, 27 Jan 2012 16:48:22 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) |
Hi Ian and David,
On Fri 25 Nov 2011 12:15, Andy Wingo <address@hidden> writes:
> On Fri 25 Nov 2011 11:37, David Kastrup <address@hidden> writes:
>
>> 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.
2.0 now has the-environment and local-eval again (though not
procedure-environment). Import the (ice-9 local-eval) module to have
access to these forms. Hopefully at this point we have solved this
issue; please give it a try, and open a new bug if something comes up.
Cheers,
Andy
--
http://wingolog.org/
--- End Message ---