Re: [GLISS] Music functions using keyword parameters?

[David Kastrup]

Ian Hulin <address@hidden> writes:

> This is just a toe-in-the-water enquiry.
>
> Given the work David put in to allow optional music function parameters
> in the 2.16 release, how much work would it be able to do something like
>
> \afterGrace :#note d1 :#grace { c16[ d]} :#fraction 15/16
> or
> \afterGrace :#fraction 15/16 :#note d1 :#grace { c16[ d]}
>
>
> Notes:
> Both the above would produce the same output.
> I've used the default Scheme keyword introducer ':#' for the keyword.

Uh no.  The default would be '#:'.  In order not to introduce yet
another special case in the lexer, using ##: from LilyPond would seem to
make sense.

> I know currently \afterGraceFraction needs to be defined in Scheme
> as
> #(define afterGraceFraction (cons 15 16))
> to do this rather than use a rational.

Sigh.  Why not just use an ordinary optional argument here?  15/16 in
LilyPond syntax gets translated to (cons 15 16) anyway.  The actual
problem right now is that a mandatory argument after a non-present
optional argument needs to be "closed" music.  With \afterGrace, not
being able to use a simple note without braces would be embarrassing.

But that's on the agenda to fix.

> Is this feasible?

Likely.

> Is this desirable?

Unlikely.

> Specifically, does it cause huge disruption with the current
> parser/lexer code.

Pretty much.  The lexer could remain unchanged when heeding the above
change suggestion.  The parser would be invasive.  Probably somewhat
straightforward, but invasive.  Keyword arguments would likely have to
come first.

> Thoughts please? Especially welcome from those who've got down and
> dirty with the parser code.

The stuff for matching LilyPond arguments to signatures would have to be
reworked.  Not as much messing with the parser as with the parser
support code (like define-music-function, and the syntax constructors).

I don't like the consequences on the syntax.  We have sort of a
"keyword" interface in unquoted strings, like \tweak takes as an
optional argument.  Meddling with "true" keywords causes more fine
distinctions than I care for.  I think that it is saner to try matching
semantics to the existing optional arguments, and I think that this will
become reasonably straightforward in the case of \afterGrace once the
"closed" issue disappears.  Actually, I think that if you don't use an
optional fraction but rather a _duration_, the "please be closed" issue
might possibly be absent with the current code base.  I don't promise
that this might not change transitorily, however, so it would probably
not make much sense to design a possibly inferior interface based on
that.

-- 
David Kastrup