There is an old mathematical/engineering tradition of distinguishing
the meanings of the minuscules and majuscules of the same alphabetic
letter.
A may denote some array and a(i,,j)---not A(i,,j)---one of its
elements. A set may be represented as S = {s(1), s(2), . . . ,
s(j), . . . , s(n)}. T and t are different in many thermodynamic and
information-theoretic expressions in which both of them appear.
Examples of this kind are very common indeed, some common that in IN
SOME CONTEXTS this distinction is expected, while in other,
non-technical ones it is not.
What is appropriate is thus contextual and thus also problematic. We
programmers are a motley crew. Each of us is a creature of his/her
own specific experience; and no convention is likely to be congenial
to all of us.
For this reason I try in my own programming to avoid case-sensitive
schemes. If, say, a macro keyword parameter, call it &keyword, can
have one of the two notional values keyword=no or keyword=yes, I
arrange matters so that any case-independent disambiguating truncation
(CIDT) of one or the other is functionally equivalent. This amounts
to accepting, for example, any of no, nO, No, NO, n, or N as
equivalent; and since this would be tedious to do ad hoc it and all
similar tasks are relegated to a table-driven macro.
I am not an unconditional admirer of dumbing things down to make them
accessible to joe sixpack, but in this case consensus is not
achievable, and case-insensitivity seems to me to be the best
compromise available. If everyone were a mathematician case
sensitivity would be feasible, but I suspect that such a universe
would be disagreeable in other ways.
John Gilmore, Ashland, MA 01721 - USA
