Re: [GLISS] - alternative viewpoint

[David Kastrup]

"Phil Holmes" <address@hidden> writes:

> ----- Original Message ----- 
> From: "David Kastrup" <address@hidden>
> To: <address@hidden>
> Sent: Saturday, September 15, 2012 9:20 AM
> Subject: Re: [GLISS] - alternative viewpoint
>
>
>> "Phil Holmes" <address@hidden> writes:
>>
>>> And getting rid of case-sensitivity in a lot of this?
>>
>> You need to elaborate.  It is not clear what you mean with that, and
>> what kind of remedy you envision.
>
>
> \new Staff works.  \New staff doesn't.  There's no reason for that -

There is actually a reason for that.  Staff, as a context name, is a
container for properties, and things like Slur, as a property name, are
also principally containers for properties.  There is a convention to
uppercase them in order to distinguish them from other elements.  When
writing things like

\layout {
  \context {
    \Staff
    \override ...
  }
}

calling the identifier \Staff for copying an existing context definition
is not syntactically different from calling any other kind of identifier
including functions.  We use the uppercasing here in order to establish
some kind of namespace.

The one consequence that I find actually annoying about that is that we
have the semi-equivalence of \score with \new Score, and that is indeed
less than pretty.

> we don't have two separate \new \New commands that do different
> things, nor two contexts Staff and staff that are different.

But \Score and \score which are entirely different things (the latter is
actually a reserved word, so they can't really be merged).

> Worse is that \slurUp works but only with that precise casing.

Given that it works on a grob called Slur, I agree that some of the
consequences of our naming schemes are not necessarily fortunate.
\upSlur would fit better into the schemes, but I don't fancy its
grammar.  In practice, \voiceOne and \voiceTwo are more often than not
the saner choice (as they make for more consistent results usually since
the user often forgets to include the more obscure *Up/*Down commands),
or using ^ and _ on individual slurs (since it is rare that you actually
want to direct only slurs but nothing else for longer passages).

> TBH this specific one doesn't cause me worry, since I remember it, but
> there are much more arcane casings that I have to refer to the manual
> to find - so I can remember the command, but not the casing!  From a
> user perspective, it would be much simpler if everything they write
> was ToLower()-ed before further processing.

With the current design, it is not as simple as that right now.  Of
course, there is the standard argument (known from filesystem
discussions) that lowercasing is not a well-defined operation since some
people expect \lowercase{I} to be {i} and some expect it to be {ı} and
\uppercase{i} to be either {I} or {İ}.

As long as we allow arbitrary utf8 characters into identifiers, that is
not an entirely hypothetic consideration.

-- 
David Kastrup