Werner LEMBERG <[email protected]> writes:

>>> I'm strictly against case-insensivity.
>> 
>> And I and others are for it.  Could you state your reasoning,
>> please?  I've already stated mine.
>
> First, it is confusing.  Virtually all programming languages of today
> (and lilypond's input code resembles that) are case-sensitive.
>
> Second, as David has already mentioned, the conversion to either
> lowercase or uppercase is locale dependent.
>
> Third, the numbers of short user-definable abbreviations gets halved.
> Something like
>
>   F = \markup { "Horn in F" }
>
> would no longer be possible because \f is already in use.
>
> Fourth, Scheme is not case-insensitive.

That's not traditional.  However, the current R6RS syntax states

       Case is significant except in representations of booleans, number
    objects, and in hexadecimal numbers specifying Unicode scalar values.
    For example, `#x1A' and `#X1a' are equivalent.  The identifier `Foo'
    is, however, distinct from the identifier `FOO'.

Guile has

    6.17.1.4 Case Sensitivity
    .........................

    Scheme as defined in R5RS is not case sensitive when reading symbols.
    Guile, on the contrary is case sensitive by default, so the identifiers

         guile-whuzzy
         Guile-Whuzzy

       are the same in R5RS Scheme, but are different in Guile.

       It is possible to turn off case sensitivity in Guile by setting the
    reader option `case-insensitive'.  For more information on reader
    options, *Note Scheme Read::.

         (read-enable 'case-insensitive)

       Note that this is seldom a problem, because Scheme programmers tend
    not to use uppercase letters in their identifiers anyway.

in its documentation, so the previous Scheme default has been different.

> Should everything starting with `#' be case-sensitive then?  Otherwise
> we couldn't fully access our own extension language.

I doubt Guile makes use of different case versions in the predefined
stuff.

But LilyPond does.

-- 
David Kastrup

_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Reply via email to