parser.yy contains the following code:
music_function_identifier_musicless_prefix: MUSIC_FUNCTION {
SCM sig = scm_object_property (yylval.scm, ly_symbol2scm
("music-function-signature"));
if (scm_is_pair (sig) && to_boolean (scm_memq (ly_music_p_proc, scm_cdr
(scm_reverse (sig)))))
{
PARSER->parser_error (@$, "Music function applied to event may not have a
Music argument, except as the last argument.");
}
}
;
This error check can never trigger since
music_function_identifier_musicless_prefix is used only in grammar rules
where the function signature meets the restraints: it is nonsensical to
check for the presence of a shift-reduce conflict at runtime when one
has eliminated the conflict from the rule set already.
If one uses the following code:
zap=#(define-music-function (parser location one two) (ly:music?
ly:music?)
#{ #} )
{ c-\zap c c-2 }
which is exactly the scenario that is supposed to be caught, the
resulting error message is
lilypond /tmp/junk.ly
GNU LilyPond 2.15.6
Processing `/tmp/junk.ly'
Parsing...
/tmp/junk.ly:3:9: error: syntax error, unexpected EXPECT_MUSIC
{ c-\zap
c c-2 }
/tmp/junk.ly:3:0: error: errors found, ignoring music expression
{ c-\zap c c-2 }
One would need a rule including the "error" symbol and a generic music
expression as a fallback, avoiding the shift-reduce conflict. Since the
rule would trigger only in the case of an error and an available
non-unique music expression, the condition would not require checking,
being reasonably clear.
Fixing this is a low priority (it went unnoticed so far and only
concerns the legibility of the error message and recovery). I intend
working in that area anyway and would likely relax the requirements in a
manner that only prescribes using grouped music in a limited number of
contexts.
--
David Kastrup