Re: Input variables and Scheme

[Michael Welsh Duggan]

Michael Welsh Duggan <address@hidden> writes:

> Michael Welsh Duggan <address@hidden> writes:
>
>> Michael Welsh Duggan <address@hidden> writes:
>>
>>> Either the documentation for 12.2.1 "Input variables and Scheme" is
>>> deprecated, or somthing is broken.  Using the following input:
>>>
>>> \version "2.9.19"
>>>
>>> traLaLa = { c'4 d'4 }
>>>
>>> #(define newLa (map ly:music-deep-copy
>>>   (list traLaLa traLaLa)))
>>> #(define twice
>>>   (make-sequential-music newLa))
>>>
>>> { \twice }
>>>
>>> I get the following output:
>>>
>>> lilypond -f ps /home/md5i/lily/test27.ly
>>> GNU LilyPond 2.9.19.mwd
>>> Processing `/home/md5i/lily/test27.ly'
>>> Parsing.../home/md5i/lily/test27.ly:2:3: While evaluating arguments to list 
>>> in expression (list traLaLa traLaLa):
>>> /home/md5i/lily/test27.ly:2:3: Unbound variable: traLaLa
>>
>> Both this and the subsequent bug I have posted are rooted in the same
>> problem.  The asignment rule in parser.yy isn't triggered until after
>> the subsequent scheme expression is lexed.  Since scheme code is
>> executed at lex time, the scheme expression is effectively happening
>> before the assignment preceeding it.
>
> One possible way to fix this problem is to pass on the result of the
> `read' call to the parser to evaluate, instead of doing both in
> ly_parse_scm (internal_ly_parse_scm).  If any of the primary
> developers think this is a good idea, I'll have a stab at implementing
> it.

I experimented with this approach this weekend.  This approach is
infeasable without fairly major parser modifications, as scheme
expressions are converted (via Lily_lexer::try_special_identifiers) in
the lexer to one of several possible lexing tokens.

Suggestions?

-- 
Michael Welsh Duggan
(address@hidden)