Re: Case sensitivity (was Re: no title)

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Hyman Rosen <hyrosen@mail.com> writes:

> Preben Randhol wrote:
> > It is far easier to rather better to use different
>  > words than to simply change the case.
> 
> The point remains that I may want to use the same word
> in different cases to mean different things. The C
> example of upper case as the type and lower case as the
> object is an example. Ada says I can't do that. Why?
> Because having one English word mean two different things
> is confusing? But Ada already allows that. So it's an
> arbitrary decision made by people who don't like case
> sensitivity forcing their view on those who do.

Well, that last sentence is sort of silly.  *Every* rule of every
programming language is a decision made by people forcing their decision
on other people don't like that rule.  Call it an "arbitrary" rule, if
you like.  ;-)

Anyway, what lots of folks seem to be missing is that there are more
choices than "case sensitive" or "case insensitive".  The rule I favor
would be for overload resolution to be case insensitive, but to have an
extra legality rule saying you have to use the right case.  This is
essentially what you get if you use the GNAT switch that somebody
mentioned.  For example:

    procedure FOO(X: Integer);
    procedure Foo(X: Boolean);

    Foo(True);

would use types, and not case, to resolve which foo you're talking about
(the Boolean one).  But if you say:

    FOO(True); -- illegal

it would still resolve to the Boolean foo, but you get an error because
you spelled it with the wrong case.  FOO(123) would be OK.

If we further allow everything to be overloaded (not just subprograms,
and then bogusly pretend that enumeration literals are subprograms),
then your example:

    function Put(string: String);

would be fine.  Presumably, the "String" after ":" would resolve to the
type name in Standard, since that's what is expected after ":".  ("The
type of type is type.")

The case sensitive rule says you can declare "Foo: Integer; FOO: Integer;",
which is clearly confusing.  The case insenstive rule says you can't do
that, but you can declare "Foo: Integer;" and then refer to it as FOO,
which I think damages readability.  The more complicated rule I outlined
above solves *both* problems.

Somebody elsewhere in this thread denigrated this:

    function Put(string: String);

as being too "lazy" to come up with good names.  I don't agree.
We've had endless debates as to whether it should be "A_String: String"
versus "String: String_Type" and all kinds of other variations on
those.  But it seems to me that "string/String" is a perfectly good
name for a type, and for a parameter of that type.  A_String doesn't
help; it doesn't add any information (references make it obvious on
context).  And with this idea, case helps distinguish, but can never
confuse.  A language should not be about punishing programmers who are
too "lazy" to jump through hoops, but should be about aiding the writing
of readable code.

Many folks have advocated using more-descriptive names for the objects.
For example, City_Name instead of A_String.  That's of course a good
idea when there *is* a more descriptive name, but for general-purpose
parameters, it doesn't work.  Put takes *any* string; there is no
adjective such that Adj_String would aid understanding of the program.

Of course, neither the Ada rule nor the C rule is going to change.  (I'm
on the ARG, and I would certainly never vote for a grossly incompatible
language change!)  I just find it interesting to discuss better
alternatives.

- Bob