Re: Dot-separated list as music function argument

[David Kastrup]

Jan-Peter Voigt <address@hidden> writes:

>> On 08.07.2014 13:58, Jan-Peter Voigt wrote:
>>> I also stumbled sometimes ove this behaviour, but I think it is not a
>>> "real" bug. If the parser has a list? predicate, it looks for
>>> dot-notation. But if it gets a custom predicate, it will not do so.
>>> Am I right, David?

No.  If we have some Word in the place of a function argument, LilyPond
tries interpreting it as a string first.  If the predicate refuses to
accept that, the next try is as a one-element symbol list.  If that gets
accepted, the parser checks whether this symbol list can be extended
with .AnotherWord following.  If the predicate refuses a symbol list,
however, LilyPond tries feeding it a single symbol before giving up.

>>> IIUC some predefined predicates (list?, string?, ly:duration?,
>>> ly:pitch?, ...) are handled in a special way to allow shorter input,
>>> but this is not "seen" by the parser, if they are wrapped in a custom
>>> predicate.
>
> ... o dear ...
> my mail was delayed one day. But thats not too bad, as the other answers
> are much more helpful.
> Still, wrapped predicates do not get any special handling by th parser.

No predicate at all gets special handling by the parser in music
functions any more (as of issue 3618, version 2.17.29).  You can wrap
them all you want.  LilyPond actually calls the predicates (often
several times, sometimes on partially parsed input) to make its parsing
decisions.

But then that change has not had a lot of publicity: you'll see that
(apart from administrative comments) I have been the only commenter on
issue and code review.

Things are different for markup command arguments: those have not gotten
the whole treatment that music/scheme function arguments have.  It would
be a completely different bag of tricks to do so in markup mode.

-- 
David Kastrup