Re: how to make decisions?

[Keith OHara]

David Kastrup <dak <at> gnu.org> writes:

> 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 prize for
> beauty.
> 
This is interesting.  LilyPond has used context to know that in
   \paper {line-width = 16.\cm}
the '-' is part of the variable name, the '16.' a decimal number, and the 
\cm a predefined dimension -- as opposed to
    cm = {c16. d64 e_- } \new Voice \cm

We have been required to use Scheme to write decimal numbers, everywhere 
outside of \paper{} and other headers
   midiMaximumVolume = #0.7

Is this why you let '-' and '_' in identifiers out of their previous 
confines?  I thought you wanted them in music identifiers. (Others have 
requested the '_' at least.) 

How far do you foresee merging the syntax in \paper {} with that in note-entry 
mode? 

> > I've seen complaints in non-Lilypond forums that LilyPond pitch entry 
> > is not relative to key signature.  We could accommodate this ...

> My personal take on this is "no".  Reason 1 ... 2 ...

Absolutely.  I'll just point out where one person who tried out Lilypond
was innocently transparent in his bewilderment that anyone would call 
out fis in the key of D, and quietly denote the unusual F-natural as f.
http://www.johndcook.com/blog/2009/03/15/typesetting-music-in-latex-and-
lilypond/
Notice the phrase "the Fs are sharped" rather than "the key has F-sharps"

> > 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.
> 

This begs for an expressive example.