Implement partial function calls and markups

Implement partial function calls.

Contains three commits, see particularly the regtests as examples.

I'm not convinced this idea is as good as I thought when coming up
with it: it may be that this particular use case is not frequent
enough to warrant the complexity.

It seems nice for defining aliases like

tagv = \tag '(violinI violinII) \incomplete

or

important = \tweak color #red \tweak font-size 3 \incomplete

but I'm not sure that this warrants the effort.

Discuss.


Allow for chaining of several partial functions in a row

Chaining only works when all function calls except the last one have all
arguments supplied already, with their last argument being the rest of
the chained call.

Implement partial function calls

A partial function call acts as a function where the start of the
argument list has already been supplied.  For example:

makeRed = \tweak color #red \incomplete

Then one can use this as

{ c' \makeRed d' e'-\makeRed -. }


Also contains partial markups:

A partial markup acts as a chain of markup commands where everything but
the final markup has already been supplied.

For example:

bold-red-markup = \markup \bold \with-color #red \incomplete

\markup \bold-red "text"
\markuplist \column-lines \bold-red { One Two Three }

Please note that in order for \markup to recognize the resulting markup command inside of markup expressions, the identifier to which the resulting markup command is assigned needs to have "-markup" appended to its name: LilyPond encodes markup command names in this manner so that markup commands can use the same name as other entities outside of markup mode.

Note also that this will not work with the markup macro since the latter additionally requires the definition of a suitable make-bold-red-markup command.

[Trevor Daniels, 2015-07-10 10:34:24]

If I understand this correctly it permits a variable definition to be used in
some circumstances where a music function definition would previously have been
required to achieve the same effect.  That seems a worthwhile improvement and
simplification.

Trevor

[mark_opus11.net, 2015-07-10 10:50:55]

On 2015/07/10 10:34:24, Trevor Daniels wrote:
> If I understand this correctly it permits a variable definition to be used in
> some circumstances where a music function definition would previously have
been
> required to achieve the same effect.  That seems a worthwhile improvement and
> simplification.

Will this also work with \markup? e.g.:

redBold = \markup \with-color #red \bold \incomplete

\redBold "text"

[dak, 2015-07-10 11:00:26]

On 2015/07/10 10:34:24, Trevor Daniels wrote:
> If I understand this correctly it permits a variable definition to be used in
> some circumstances where a music function definition would previously have
been
> required to achieve the same effect.

Well, tiny correction: it just _looks_ like a variable definition.  What falls
out is a music function definition (or event function or scheme function,
depending on what the last function call happens to be).

It's mostly syntactic sugar (arguments present in the definition are not
evaluated and typechecked again, so it's a bit better than open-coded when
looking at stuff like a long tweak cascade).

> That seems a worthwhile improvement and simplification.

The main problem I see is that if your only tool is a hammer, you start viewing
your problems in terms of nails.  This works for a cascade of tweaks, but, say,
not for overrides.  So you make it work with an override only to realize
overrides don't cascade but are placed in sequence.  Oops.  So you want
xxx = { ... \incomplete } as well.  And so on.

So what I fear is that it's opening a can of worms because people would like to
be able to do more in that manner.  And it might be hard to stuff the genie back
into its bottle again...

[dak, 2015-07-10 11:17:37]

On 2015/07/10 10:50:55, mark_opus11.net wrote:
> On 2015/07/10 10:34:24, Trevor Daniels wrote:
> > If I understand this correctly it permits a variable definition to be used
in
> > some circumstances where a music function definition would previously have
> been
> > required to achieve the same effect.  That seems a worthwhile improvement
and
> > simplification.
> 
> Will this also work with \markup? e.g.:
> 
> redBold = \markup \with-color #red \bold \incomplete
> 
> \redBold "text"

A nice illustration of my "can of worms" theory.

It would be quite straightforward to make this work for the case where there is
only a final markup missing since the grammar already special-cases this kind of
markup chain.

But that would be a different issue, unrelated apart from employing the same
reserved word.  Markup commands are quite different from music functions.

[dak, 2015-07-10 11:44:56]

On 2015/07/10 11:17:37, dak wrote:
> On 2015/07/10 10:50:55, http://mark_opus11.net wrote:
> > On 2015/07/10 10:34:24, Trevor Daniels wrote:
> > > If I understand this correctly it permits a variable definition to be used
> in
> > > some circumstances where a music function definition would previously have
> > been
> > > required to achieve the same effect.  That seems a worthwhile improvement
> and
> > > simplification.
> > 
> > Will this also work with \markup? e.g.:
> > 
> > redBold = \markup \with-color #red \bold \incomplete
> > 
> > \redBold "text"
> 
> A nice illustration of my "can of worms" theory.
> 
> It would be quite straightforward to make this work for the case where there
is
> only a final markup missing since the grammar already special-cases this kind
of
> markup chain.

Well, oopsy daisy.  It's quite uncomplicated with regard to the grammar.  But
there is a tiny complication: as opposed to music functions et al, markup
commands have a different namespace, are supported by the markup macro, and are
not anonymous: defining a markup command does not just define one name but a
whole slew of them.

So

redBold = ...

cannot define a markup command (and never could).  I could instead define a
scheme command returning a markup.  I think that those should work in comparable
circumstances.

[dak, 2015-07-10 12:56:10]

On 2015/07/10 11:44:56, dak wrote:

> redBold = ...
> 
> cannot define a markup command (and never could).  I could instead define a
> scheme command returning a markup.  I think that those should work in
comparable
> circumstances.

This is seriously funny.  I happened to discover an old (more than a year)
branch of mine lying around that very much does all of this with regard to
markups and works around most of the related problems.  It uses "\default"
instead of "\incomplete" and the syntax rules use different names and places and
concepts but it should be quite easy to fit that old branch in here: the work
appears all done (though I don't know how much, if any, testing I did and
whether or not this was in working state).  Won't likely support the markup
macro, though.

[dak, 2015-07-10 14:52:42]

Implement partial markups

[Dan Eble, 2015-07-11 02:24:58]

I appreciate your comment about this opening a can of worms, but I do like the
simplification.

Now I'll open a can of my own: instead of \incomplete, how about \etc?

[dak, 2015-07-11 05:11:07]

On 2015/07/11 02:24:58, Dan Eble wrote:
> I appreciate your comment about this opening a can of worms, but I do like the
> simplification.
> 
> Now I'll open a can of my own: instead of \incomplete, how about \etc?

That's at least not overly likely to be used previously.  Other possibilities
may be symbols like ; or so.  ... is out since it is in active use as part of
durations.  I thought of using \{ ... \} which has the advantage of delimiting
to the left as well, allowing

omit = \with-doc-string "This does xxx" \{ \tweak stencil #f \}

However, this does not seem overly important, one can do

omit = \tweak \stencil #f \etc
omit = \with-doc-string "This does xxx" #omit

Does not look as pretty, but which end user is going to set a doc string on his
functions?

And \{ ... \} seem nice to leave open for used-defined articulations.

[dak, 2015-07-11 06:48:17]

On 2015/07/11 02:24:58, Dan Eble wrote:
> I appreciate your comment about this opening a can of worms, but I do like the
> simplification.
> 
> Now I'll open a can of my own: instead of \incomplete, how about \etc?

With regard to full words, \adjourn would seem to match the functionality well. 
\etc has the advantage of being concise.  The real meaning is "to be continued"
but I cannot think of some reasonably short Latin phrase bastardized into
English that would express that.  "\etc" is not quite that but it _is_ rather
idiomatic.

So short of better proposals arriving, I am inclined to change this to \etc.  In
order not to inundate the testers with patches while we might still come up with
something better, I'll wait for the countdown to do this change.

[thomasmorley651, 2015-07-11 11:18:52]

Will this allow
trans-cis = \transpose c cis \etc
?
Then I'd say it's a great improvement.

Far better than having to do:

my-trans =             
#(define-scheme-function (parser location from to) (ly:pitch? ly:pitch?)
   (define-music-function (parser location music) (ly:music?)
   #{ \transpose $from $to $music #}))
   
trans-cis = \my-trans c cis

[dak, 2015-07-11 12:51:04]

On 2015/07/11 11:18:52, thomasmorley651 wrote:
> Will this allow
> trans-cis = \transpose c cis \etc
> ?

That would be a straightforward use, yes.

> Then I'd say it's a great improvement.

Huh.

> Far better than having to do:
> 
> my-trans =             
> #(define-scheme-function (parser location from to) (ly:pitch? ly:pitch?)
>    (define-music-function (parser location music) (ly:music?)
>    #{ \transpose $from $to $music #}))
>    
> trans-cis = \my-trans c cis

See, that's my problem with estimating the usefulness of the proposal.  I don't
see why one would not be writing \transpose c cis instead of \trans-cis in the
first place, and why one would write a transposer-definer to avoid this.  Even
if one did, it would look a bit nicer these days:

my-trans =
#(define-scheme-function (from to) (ly:pitch? ly:pitch?)
  (define-music-function (music) (ly:music?) (transpose from to music)))

By the way, I am tempted to eventually introduce a different syntax for the
signatures, and then one could allow for currying, making this

my-trans =
#(define-music-function (((ly:pitch? from) (ly:pitch? to)) (ly:music? music))
   (transpose from to music))

But that's not here yet and currying is not the most obvious programming style
anyway.

So at any rate, there is a small space between just using music expressions and
using music functions, and the recent work for removing clutter from music
function definitions makes this even smaller.  I'm not all that sure that the
space in between is worthwhile filling.

But I count your comment as a definite "yes".

[wl_gnu.org, 2015-07-11 18:37:02]

> And \{ ... \} seem nice to leave open for used-defined
> articulations.

I favour \etc also.


    Werner

[treda_treda.co.uk, 2015-07-11 18:53:57]

Werner LEMBERG wrote Saturday, July 11, 2015 7:36 PM

>> And \{ ... \} seem nice to leave open for used-defined
>> articulations.
> 
> I favour \etc also.

Me too.

Trevor

[dak, 2015-07-12 23:24:46]

\incomplete -> \etc, add Changes entry