David Kastrup <[email protected]> writes:
>> The Lilypond codebase does not contain such music function arguments I
>> think. It should actually work to convert them to
>> #(ly:export (ly:make-pitch ...
>> so there is a straightforward (but more likely than not untowardly
>> awkward) migration path.
>>
>> Apart from this change in semantics, this should not cause
>> regressions.
Reconsidering this matter, I have come to the realization that one could
avoid regressions here simply by still permitting Scheme expressions
(and passing them through the specified validator like ly:pitch?).
I see advantages and disadvantages to that approach.
pro: One can provide more and more specially parsed arguments on a
contingency base without invalidating previous code.
contra:
This promotes code sloppily interchanging Lilypond and Scheme
as music function arguments, making music functions behave
differently from "built-in" Lilypond commands.
Upgrading code to use ly:export when a predicate becomes specially
recognized is rather trivial.
Intermediate strategy:
Allow Scheme for newly converted specially parsed arguments, and
deprecate and phase out after a while.
Frankly, I consider the bookkeeping for that going a bit overboard for
now.
So my plan would be to just press forward and see whether anybody
complains.
> I put the current state up on Rietveld at
> <URL:http://codereview.appspot.com/4811047>
>
> I don't have a usage example to go with the patch though. If somebody
> has something nice to offer...
Again: usage example would be welcome.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
