lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: recursive music function definitions broken in 2.14 ?


From: David Kastrup
Subject: Re: recursive music function definitions broken in 2.14 ?
Date: Mon, 03 Oct 2011 17:58:13 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> Juha Erkkila <address@hidden> writes:
>
>> Howdy,
>>
>> I had some lilypond code that worked in 2.12 versions, but appears
>> broken in 2.14.  I had used a construction in which a music function
>> calls itself.  Here's an example:
>>
>> ----------------------------------------------------------------------
>> tags = #(define-music-function (parser location tags music)
>>                                (list? ly:music?)
>>          (cond ((null? tags) music)
>>                (else (let ((firsttag  (car tags))
>>                            (othertags (cdr tags)))
>>                       #{ \tags $othertags \tag $firsttag $music #}))))
>>
>> foo = \tag #'a \tag #'b { c4 d e f } 
>> bar = \tags #'(a b) { c4 d e f }
>>
>> \score {
>>   {
>>     \keepWithTag #'a \foo
>>     \keepWithTag #'b \foo
>>
>>     \keepWithTag #'a \bar
>>     \keepWithTag #'b \bar
>>   }
>> }
>
> The problem here is that you are writing $othertags.  This tells
> Lilypond that it should figure out on its own what syntactic type
> $othertags should receive.  An empty list meets the markup-list?
> predicate, so Lilypond decides to consider this a markup list
> syntactically.  Which is not compatible with the list? predicate, since
> that is looking for a Scheme expression (or a simple string)
> syntactically.
>
> So just writing #$othertags should put Lilypond on the right track and
> keep it from guessing the syntactical class wrong here.
>
> markups and markup lists are somewhat peculiar: most other Lilypond data
> structures don't rely on an inner analysis for figuring out their type.
> That an empty list is classified as "markup-list?" is a bit
> disconcerting in this context.  I don't have a good idea how to do this
> better.
>
> You'll have the same problem when writing
>
> icky = #'()
>
> After that, concerning Lilypond \icky is a markup list and nothing else.

If you are saying that you remembered this working at some previous
point of time: the responsible change is

commit d5520dfd94c82e43a76adca47a8aefc71d7f6b4a
Author: Reinhold Kainhofer <address@hidden>
Date:   Tue Jan 4 15:14:10 2011 +0100

    Allow \markuplines to be stored in a variable and inserted later on in the 
parser


Mike, are you reading this thread?  Seems like material for the upcoming
markup workshop in Paris.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]