Re: Optional arguments of a music-function?

[David Kastrup]

Thomas Morley <address@hidden> writes:

> 2012/7/17 David Kastrup <address@hidden>:
>> Thomas Morley <address@hidden> writes:
>>
>>> Trying a code like the tiny example below fails.
>>>
>>> proc =
>>> #(define-music-function (parser location name arg)((string?) ly:music?)
>>>   (if name
>>>   #{ \once \override $name #'color = #red  $arg #}
>>>   #{ \parenthesize $arg #}))
>>>
>>> \relative c' {
>>>         c1
>>>         \proc "NoteHead" c
>>>         \proc c
>>> }
>>>
>>> Obviously I did sth wrong.
>>
>> Not obviously.  Unobviously, however, we have the situation that
>> optional arguments can only be properly checked by the parser when they
>> can be parsed without lookahead, namely are a "closed" expression, since
>> only then the parser can push the value back onto its token stack: if it
>> has already looked at a lookahead token, it does not have this option
>> since the parser state already depends on the value of the lookahead
>> token.

>> Wait a few days.
>>
>> It's the same problem as with
>> <URL:http://code.google.com/p/lilypond/issues/detail?id=2067#c19>, and
>> the idea to look at the pitch identifier only at first (rather than the
>> whole pitch) did occur to me only now.  It is conceivable that I can
>> rein this in.
>
> Can't say that I understood your explanations in all details.
> But I'm sure I can wait a few days.

Well, this is not really catchable reliably with the current
mechanisms.  I'll take the issue problem that wants to permit both

\displayMusic #(current-error-port) c

and

\displayMusic c

Now let's assume we write

\displayMusic \tweak #'color #red c-3

If we want to parse \tweak without lookahead, we have to stop after c.
Then we need to evaluate the tweak, and only then do we know its type,
and decide that we can push the whole kaboodle back onto the parser
stack since it is not of type "port".

But if we have something like \displayMusic itself, evaluating it with
both c and c-3 is not an option as it is not side-effect free.

I have some idea how to deal with that: basically music expressions that
require lookahead for parsing get a "pure" version for the sake of
making syntactic decisions, but teaching that to the parser is not
exactly trivial.  In the first iteration, I'll likely just pick the
"error default" of a function for making decisions (which is #f for a
Scheme function, *undefined* for a void function, (make-music 'Music)
for a music function and (make-music 'Event) for an event-function).
This is not quite satisfactory for functions like \tweak which can be
either, really.

For the sake of syntactic decisions, something like 4 / 5 being
equivalent to the LilyPond FRACTION 4/5 does not really work as the
lookahead free version "4" has an utterly different type than 4/5 (which
is a pair of numbers).  So retiring the fraction representation 4 / 5
makes a lot of sense (I think that's a separate issue on countdown
already).

-- 
David Kastrup