Re: Proposed new available and recommended behavior of \relative

[David Kastrup]

Robert Schmaus <address@hidden> writes:

> On Fri, Mar 8, 2013, at 09:06 AM, David Kastrup wrote:
>> Robert Schmaus <address@hidden> writes:
>> 
>> > Hi everyone,
>> >
>> > I haven't read all posts on this subject, so sorry should I write
>> > something that's already been written.
>> > Why not keep the \relative <pitch> { <music> } syntax as one supported
>> > way and simply change the \relative { <music> } syntax to what David
>> > proposed?
>> 
>> Uh, that was the plan anyway.  The question was rather whether we should
>> convert to using the second form preferably in documentation and
>> examples.
>
> Oh, sorry, I interpreted your remark from an earlier mail ("But when
> upgrading, convert-ly will convert it to the form without explicit pitch
> if it can.") in that way, that the \relative <pitch> { <music> } is
> planned to disappear ultimately.

No, so strictly speaking \relative x''' { x is always going to be
available as the kind of "lever" you are talking about.  It just becomes
less elegant.

>> > I myself have always only used the first version (I didn't even know
>> > the other existed, to be honest), and I liked the idea of having a
>> > lever outside the music that shifted the music ocave-wise.
>> 
>> \transpose c c'' is such a lever.
>
> I have thought of that too - it's just that transposition for me is
> something I'd apply to a complete score in concert pitch e.g. to
> produce a music sheet for Bb instruments.

\transposition is there for the purpose of setting the relation between
sounding and printing pitch.  \transpose is independent from that.
Granted, it only became independent very recently: before both were
weirdly intertwined.

>> > Or, as an alternative, the \relative { <music> } syntax could rely
>> > on music that was written *before* the relative block.
>> 
>> That one is not an actual alternative.
>> 
>> xxx = \relative { c d e f g }
>> yyy = \relative { c d e f g }
>> 
>> \new Voice { \yyy \xxx }
>> 
>> Now what is the music "written before the relative block"?  The whole
>> point of \relative is that it returns absolute music given relative
>> music.  You propose it should return relative music given relative
>> music.  But how would music then become absolute?
>
> It would, if there's either a default (pitch) for \relative { ... } with
> no music before it.

What is your definition of "before"?

> Or if the compiler gives an error if a user were to write something
> like your example. After all, it's always up to the typesetter to
> write something that makes sense.

But computers are not interested in making sense but rather in following
instructions.  So to give an error when something does not make sense,
you need well-defined rules for what makes sense and what not.  And I
don't see a reasonable cut-off point for that.

>> Making this proposal work in a sensible and predictable manner would
>> be quite harder than it might appear.
>
> There are probably not many persons who would know this better than
> you do ...

It's not as much a matter of _implementing_ this proposal but rather of
making a coherent definition of what this proposal should exactly be.

If there is no manner to convert the idea into a set of coherent rules
that a human could follow reliably, there won't be a set of coherent
rules for the computer either.

> and I don't think that any of what lilypond can produce is quite as
> easy as it appears! Each time I use it, I am amazed by something new!

"amazed", "caught on the wrong foot", and "unpleasantly surprised" are
different things.

"It did just what I thought it would, only better" is what we want to
arrive at.  Or at least "my mistake was obvious".  So "can we make it
guess better what I mean" is a trap: LilyPond should not need to guess
your meaning, nor should you need to guess its actions.  If guesswork is
involved, the human/computer interface is broken.

-- 
David Kastrup