Re: recursive music function definitions broken in 2.14 ?

[David Kastrup]

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 point here is that both \foo and \bar should give equivalent
> results when used with \keepWithTag.  The function \tags takes
> a list of tags and applies them to a music expression.
>
> With 2.12 this used to work (I don't have one to test here with,
> but I'm quite sure), but with 2.14.2 I get this:

> <string>:1:39: error: syntax error, unexpected MARKUPLINES_IDENTIFIER
> parseStringResult = \notemode {  \tags 
>                                        \lilyvartmpbg \tag \lilyvartmpbh 
> \lilyvartmpbi  }foo.ly:12:2: error: errors found, ignoring music expression
>   
>   {
> foo.ly:0: warning: no \version statement found, please add


> Perhaps some definition in straight scheme might also work here?
> Any ideas?

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.

-- 
David Kastrup