Han-Wen Nienhuys <[email protected]> writes:
> On Sun, Nov 6, 2011 at 5:11 PM, Ian Hulin <[email protected]> wrote:
>> Hi all,
>>
>> A couple of questions in case someone with more internal code-fu than me
>> can save me rummaging around in the guts of the C++ code, just so I can
>> get a handle on some behaviour I've noted trying to get LilyPond to fire
>> up with Guile V2.0.3.
>>
>> 1. Does processing a file via \include cause a new LilyPond scope ->
>> generating a new "anonymous" Guile module for that file?
>
> no.
>
>> 2. How and when does a LilyPond assignment
>> blah = { lily-statements... }
>> get compiled down in to a scheme (define blah .... )?
>> Guile V2 complains about stuff like
>> ignatzekExceptionMusic = { blah blah2 blah3}
>
> this happens when the parser decides it can reduce the input to an assignment,
>
> assignment:
> assignment_id '=' identifier_init {
> PARSER->lexer_->set_identifier ($1, $3);
> }
>
>
> the actual work is in the function
>
> scm_module_define (mod, sym, val);
>
> there is some trickiness with ordering. The parser may do look ahead
> up to the #( .. ) you have before it decide to do the reduction.
>
> In doubt, you can force it by inserting a dummy scheme statement in
> between both assignments.
I currently have a patch in review (will submit a regtest-passing
version in the next hour) that makes $... take over the job of
#(ly:export ...) in general instead just half-bakedly in #{ ... #}.
Once ly:export is retired, # can be made to just _read_ a Scheme
expression in the lexer, and let the _parser_ evaluate it when it is
used (this is not possible while ly:export is functional).
That should seriously decrease the potential for Premature Evaluation.
Until then, #(begin) is a good interjaculation.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
