Re: Internals questions - \include and LilyPond assignments

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Sun, Nov 6, 2011 at 5:11 PM, Ian Hulin <address@hidden> 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