Urs Liska <u...@openlilylib.org> writes:
> Am 28.06.2016 um 11:05 schrieb David Kastrup:
>> Urs Liska <u...@openlilylib.org> writes:
>>
>>> Hi all,
>>>
>>> I am surprised that \include refuses to accept a string that isn't
>>> passed literally but through a scheme-function:
>>>
>>> \version "2.19.43" givePath = #(define-scheme-function ()()
>>> "some/path/that/will/probably/not/be/found.ily") #(display (givePath))
>>> \include \givePath
>> \include is not a scheme function. It switches input at a very low
>> level. \include is not even a reserved word and it never gets turned
>> into a token. It is a pattern of bytes causing an immediate reaction in
>> the lexer. That it accepts a #xxx or $xxx expression is hard-coded
>> right in the lexer: it does not pass through the normal parser
>> mechanisms for these constructs.
>>
>> Basically you are expecting something akin to the #include of the C
>> preprocessor to accept calls of functions defined in C for specifying
>> the file to include.
>>
>
> Thank you for the explanation.
> Interestingly Harm provided a solution presumably working,
"working" is not the same as "doing something". To wit:
givePath =
#(define-scheme-function ()()
"some/path/that/will/probably/not/be/found.ily")
\include #(givePath)
givePath is not executed by the parser at all but merely called from
Scheme, which makes the above a complicated way of writing
#(define (givePath) "some/path/that/will/probably/not/be/found.ily")
and using Scheme for calculating an expression to \include . Nothing is
interpreted by LilyPond's parser here with regard to the \include .
--
David Kastrup
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
