lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Implement partial function calls. (issue 249670043 by address@hidden


From: dak
Subject: Re: Implement partial function calls. (issue 249670043 by address@hidden)
Date: Sat, 11 Jul 2015 12:51:04 +0000

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".

https://codereview.appspot.com/249670043/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]