Valentin Villenave <valen...@villenave.net> writes:
> On Sun, Oct 31, 2010 at 5:29 PM, David Kastrup <d...@gnu.org> wrote:
>> Perhaps I have not put myself forward reasonably clearly: the idea was
>> not just to use a predicate in the function signature, but to let that
>> predicate be special-cased in the parser. The function expands to a
>> number of tokens representing the signature constituents (that is
>> already being done, we just need another token type), and then those
>> signature tokens are used for interpreting the actually upcoming tokens.
>
> Then we'd end up breaking all backwards compatibility with the old
>
> \relative { c' d e }
>
> syntax, wouldn't we? (Since \relative would expect a pitch, not a
> music expression.)
Huh? Why would \relative be affected?
> Besides, apart from \relative and \transpose, how many actual commands
> would require a pitch argument?
I really don't understand what you are talking about.
I was talking about the ability to _define_ music functions taking a
pitch argument. Not about changing existing commands.
> For all other commands, especially music-functions, the ability to
> have an argument that's either a single note or a whole music
> expression is a (really really nice) feature, not a bug :)
When I define a music command that requires a _pitch_ as an argument,
trying to extract that pitch from a whole sequential music expression is
both a nuisance as well as error-prone.
For example, I want to define a music function that takes a pitch and a
music expression as arguments, then wraps all of the music expression
into the octave starting at the specified pitch.
There is absolutely no sense in specifying anything but just a pitch for
that first argument. There is no way to make "feature" out of anything
but a pitch. Anything apart from just a pitch is going to be user input
error, and should be treated as one as directly as possible, namely in
the parser, rather than having a second-guessing engine declare failure
or result in unexplicable behavior.
> Whilst (I think) I understand your proposal, I'm not sure I see the
> advantages it would bring; could you give us some examples? From a
> user point of view, what difference would it make? (Other than
> possibly making the syntax slightly less fault-tolerant?)
Less fault-tolerant? There is absolute no _use_ in "tolerating" a fault
for which there is no sensible way to deal with.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
