Re: how to make decisions?

[David Kastrup]

Keith OHara <address@hidden> writes:

> The readable \tempo "Adagio" 4. = 30~40 lacks the delimiters that most
> computer-entry formats require, which made it unusable in a \midi
> block for many years -- because LilyPond accepts decimal-point numbers
> in the midi block, for probably another good reason.  Without
> requiring delimiters it is hard to specify exactly when LilyPond
> should read 4. as a duration, and when as 4.000.

I proposed already at one point of time to require writing 4.0 rather
than 4. for the floating point number.  This will not cure a lot of use
cases, and we still have the ambiguity between 4 the duration and 4 the
integer, and -4 the fingering and -4 the integer.

Some of those can be resolved in context, but this does not help for
conversions, and we also have largely context-free situations, like in
#{ ... #} or on the right side of assignments.  At the current point of
time, I can't write things like #{ 4.0\cm #} in appropriate contexts
because 4.0 is not recognized in notemode as a real number.  Writing
#{ $4.0 \cm #} would work but it does not exactly win a price for
beauty.

> One situation where LilyPond /does/ require delimiters is
> \chordmode { c4:8 }

That's because it changes the lexer modes.  Switching back reliably is
only possible when you have a closing delimiter that can still be
scanned in the inner lexer mode, so that you are in outer lexer mode
again before even having to start looking at the next token.

> The broad question is: Require delimiters to clarify context (for
> users, LilyPond, and software importing LilyPond) -- more or less?

Where necessary.

> I've seen complaints in non-Lilypond forums that LilyPond pitch entry is not 
> relative to key signature.  We could accommodate this by re-defining pitch 
> names upon seeing 
>   { \keyAffectingEntry \d\major  ... }
> so that f means F-sharp and we have to type fn for F.  (This requires
> pushing a
> pitchname-table on a stack for every nested level of {} or <<>>)

My personal take on this is "no".  Reason 1 is that then the actual
pitch will depend on _input_ accidental rules.  That will make MIDI and
MusicXML output less predictable.  Reason 2 is that a human-oriented
linear non-graphic representation of what is usually seen graphically
should resemble the manner in which humans would talk on the phone, a
similarly linear medium.  I don't know other note language conventions,
but here in Germany you would _never_ call a fis an f just because its
accidental is contained in the key signature.  Totally unthinkable even
among amateurs.  You'd immediately get "Oh, this is supposed to be an f?
How do you tell?".  Not because of nitpicking, but because nobody would
guess that f would be used to describe a fis.

So this is at least for me a very definite "this is not even open to
consideration" area.  Of course, people deserve to be told just _why_ it
is such a bad idea.

> I used to use \cueWhile, but then switched to your \cueDuring with the
> extra parameter, and had a few mysterious errors when I forgot which
> one had the extra parameter.  David of course suggested I make a
> \cueDuring with an optional parameter.  Either way, the poor guy
> writing the .ly importer in Musescore has no hope to keep up.

Just because some part of LilyPond syntax is defined as music functions,
that does not mean that one can't describe it formally.

The poor guy writing the .ly in Musescore at least has a chance of
designing a single mechanism able to recognize _all_ variants of music
functions that we permit.  That makes it easier for him to _systematize_
his work.

> The broad question for these three is: Syntax that changes depending
> on the definitions of the functions in the input -- good or bad?

Essential to LilyPond's design and expressivity.  That does not mean
that we should not try maximizing the good aspects and minimizing the
bad aspects.

> My prediction is that LilyPond will keep its syntax that requires
> knowledge of the definition of functions to be parsed correctly, thus
> un-importable by other software,

A LilyPond-to-LilyPond conversion would at least rip out user-defined
functions and render the predefined ones, where necessary to represent
music expressions, in a predictable manner.

> .. and that LilyPond will keep its freedom from delimiters, with David
> pulling LilyPond further toward scanning the input independent of
> context.

Again, this is not achievable in the absolute.  But there is still
leeway to do better than we have.  And being able to get along with
fewer modes also means that one does not need to choose between the
respective benefits of several modes, but can profit from the
combination.

> Others certainly frame the broad questions differently, and probably
> see additional broad questions. I think we need to allow some time for
> compromise on these balances between philosophy and practicality.
>
> Many of the specific items on the GLISS list concern names of things,
> which I think is independent of the broad questions, but will solve
> some real problems.  I was quite puzzled by a question on -user
> yesterday, until I realized he had confused the purposes of
> Staff.keySignature versus Staff.KeySignature.

Ugh.  Do we really have both?

-- 
David Kastrup