Yet Another Case Question

[Tim Churches]

Lulu of the Lotus-Eaters [mailto:mertz at gnosis.cx] wrote:
> |But I will re-iterate my whacked argument: one reason for
> |case-sensitivity is that it avoids having to explain to beginners why
> |the names of things are case-insensitive but the values of things are
> |case-sensitive.
> 
> It seems almost self-evident to me that the explanatory burden of
> explaining that a 'count' and a 'Count' are different things is far
> higher.

You haven't had enough conversations with seven year olds lately. It's
not self-evident at all. In FOO (a Python-like but case-insensitive
language) :

>>> count = 'count'
>>> count == 'Count'
False
>>> count == Count
True
>>> count == 'count'
True
>>> Count == 'count'
True

In Python:
>>> count = 'count'
>>> count == 'Count'
False
>>> count == Count
NameError
>>> count == 'count'
True
>>> Count == 'count'
NameError

FOO needs to two rules to explain this behaviour, one for names and one
for values, whereas Python needs only one rule.

A corollary of this is that in FOO, assuming that dictionaries are also
used to implement classes, properties and attributes as they are in
Python, you would need two types of dictionary hashing mechanisms: a
case-sensitive one for use when values are the keys, and a
case-insensitive one for use when the names of things are the keys.
Hmmm. Which means, at least internally, you now need to distinguish
between value-strings and name-strings. If that distinction is only made
internally (i.e. only by the compiler/interpreter), then suddenly a
great deal of introspective power is lost. If that distinction is
available to end users, well, then you have two types of strings which
have to be distinguished somehow. 

Tim C