Re: Music function extension...

[David Kastrup]

Valentin Villenave <address@hidden> writes:

> On Sun, Oct 31, 2010 at 5:29 PM, David Kastrup <address@hidden> 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