Why Case Sensitive?

[Bart]

Why is C case sensitive?

I know it's a bit late to change it now but there would seem to be far
more advantages in ignoring letter case in source code.

In real life such a situation would be ridiculous (eg. the 16 ways of
writing my name) and, in some cases, frightening.

Is it to avoid having to think up new identifiers? And how would you
distinguish case when reading out bits of code over the phone for
example?

Bart

 

[santosh]

Why is C case sensitive?

I know it's a bit late to change it now but there would seem to be
far more advantages in ignoring letter case in source code.

In real life such a situation would be ridiculous (eg. the 16 ways
of writing my name) and, in some cases, frightening.

Is it to avoid having to think up new identifiers? And how would
you distinguish case when reading out bits of code over the phone
for example?

C is case sensitive because computing systems are naturally case
sensitive. It takes extra effort to *not* be case sensitive. Input
devices like keyboards need to distinguish between cases, as do
output devices, text utilities, typesetting systems etc.

Real world is case sensitive and so are computers.

 

[Chris Dollin]

Why is C case sensitive?

Because there's no good reason to make it case-insensitive, case
sensitivity comes for free, and case sensitivity allows some
useful conventions such as UPPERCASE macros and having a convenient
distinction between Types and objects.

And how would you distinguish case when reading out bits of code
over the phone for example?

Whatever worked. The nice thing about having real people at the
other end of the phone is that you can sort out a protocol in
the cases where it matters. ("I'll email you the source" is one
such.)

I don't know about you, but I pronounce INT and int differently
when I think it might matter.

 

[Malcolm McLean]

Why is C case sensitive?

I know it's a bit late to change it now but there would seem to be far
more advantages in ignoring letter case in source code.

In real life such a situation would be ridiculous (eg. the 16 ways of
writing my name) and, in some cases, frightening.

Is it to avoid having to think up new identifiers? And how would you
distinguish case when reading out bits of code over the phone for
example?

It can be a problem, because humans remember words, not punctuation.

I use the convention that if a function depends on the standard library and
nothing else then it is all lowercase, whilst if it calls platform-specific
functions it starts with an uppercase letter.

Fortran 77 is case insensitive, and this contributes to Fortran 77 code
being quite hard to read.

 

[santosh]

[ ... ]

It can be a problem, because humans remember words, not
punctuation.

The do remember case. Case is used to indicate context specific
information in the written language. Computers that don't support
case sensitivity are like the "l33t" and "sms" type posters - ugly
and confusing to understand.

I use the convention that if a function depends on the standard
library and nothing else then it is all lowercase, whilst if it
calls platform-specific functions it starts with an uppercase
letter.

What about functions that don't call any external code, or code
that's neither platform specific nor part of the Standard C library?

 

[August Karlstrom]

Malcolm McLean skrev:

I use the convention that if a function depends on the standard library
and nothing else then it is all lowercase, whilst if it calls
platform-specific functions it starts with an uppercase letter.

If the implementation changes you may end up with naming inconsistency.


August

 

[Malcolm McLean]

Malcolm McLean skrev:

If the implementation changes you may end up with naming inconsistency.

If a function does no IO then there is no reason for it to call any
platform-specific functions, except very rarely when for efficiency reasons
a calcualtion cannot be coded in C. So separate your functions from your
procedures, and the situation cannot arise.

Unfortunately reality sometimes kicks in. For instance a lot of long
procedures work fine in development, but for commercial use they need to
support progress bars and user cancels. Error conditions can also be a
problem, as can dependencies on big datasets. Generally however the system
works.
Then of course the standard does provide methods for basic IO, which can
break.

 

[August Karlstrom]

Bart skrev:

Why is C case sensitive?

I know it's a bit late to change it now but there would seem to be far
more advantages in ignoring letter case in source code.

In real life such a situation would be ridiculous (eg. the 16 ways of
writing my name) and, in some cases, frightening.

Exactly, but on the other hand, with case insensitivity the compiler
will accept 16 different ways to refer to the object designated by BART
which imho. is even more confusing.

Is it to avoid having to think up new identifiers? And how would you
distinguish case when reading out bits of code over the phone for
example?

E.g. by spelling out each character prefixed by upper/lower or by saying
"in lower case", "in UPPER CASE", "in camelCase", "in PascalCase" etc.
before the name of the identifier.

A third alternative is to allow only one "spelling" of an identifier,
that is if an identifier is declared as Bart

1. it must be referred to as Bart and

2. the identifiers BART, bart, bArt etc. can not exist in the same scope.


August

 

[Mark McIntyre]

C is case sensitive because computing systems are naturally case
sensitive.

This is true NOW, but was not generally true prior to 1970 or so. The
first computers I worked with didn't have much in the way of lowercase
letters. There's a reason why Basic wasn't case-sensitive, and I
recall that F66 required all upper case.

Real world is case sensitive

Not entirely true either... The Romans and Greeks lived in
case-insensitive worlds.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Bart]

C is case sensitive because computing systems are naturally case
sensitive. It takes extra effort to *not* be case sensitive. Input
devices like keyboards need to distinguish between cases, as do
output devices, text utilities, typesetting systems etc.

Real world is case sensitive and so are computers.

No, in the real world Tom, tom and TOM are not considered to be
different names. And when sorting you don't really want Aardvark to
come after zebra.

Yes, some extra effort is needed to ignore case when determining
whether one name (or title, filename, etc) is identical to another.

I think a case insensitive C would have still worked well, and you
could still use upper case for macros and obey the usual conventions,
except you couldn't use the identical name, in the same scope, for a
Type and a Variable** for example; you'd need to think up something
new. [** I have a feeling someone will say these two use different
namespaces so identical names would be possible]

Bart

 

[Dik T. Winter]

> On Thu, 19 Jul 2007 15:37:17 +0530, in comp.lang.c , santosh

>
> This is true NOW, but was not generally true prior to 1970 or so. The
> first computers I worked with didn't have much in the way of lowercase
> letters.

The first computers *you* worked with... In 1965 Ascii was standardized
for the second time and that version had lower case letters. And in
1959 IBM Stretch (7030) was first purchased, which also had lower case
letters. I think around 1970 almost *all* computers had lowercase
letters. Whether you could print them on the line printers of that time
is questionable, but they could certainly be displayed on the terminals
when they were tube terminals. The first computer I worked on (back in
1969) was case sensitive. But have a look at
<http://homepages.cwi.nl/~dik/english/codes/7tape.html#start>
and find a host of very old papertape codes that include lower case
letters. The MC Flexowriter code was the first code I did use.

But the actual question is easy to answer. C ultimately derives from
Algol, and that was case sensitive. And the reason for that is easy
to explain, the computers to implement Algol were mostly in Europe, and
there case distinction was quite common in the paper-tape codes (the
most frequently used device to input programs). Using additional
translations in the compiler to make it case insensitive was prohibitive,
as memory space was scarce.

> There's a reason why Basic wasn't case-sensitive, and I
> recall that F66 required all upper case.

F66 derives from a much older language, and I think that even F66 allows
both cases in strings. Basic probably is single case (yes, originally it
*was* single case), because that was much easier.

>
> Not entirely true either... The Romans and Greeks lived in
> case-insensitive worlds.

Oh. There are many scripts that still are used and do not even have a
case distinction. But that is entirely different.

 

[Gordon Burditt]

Why is C case sensitive?

I know it's a bit late to change it now but there would seem to be far
more advantages in ignoring letter case in source code.

In real life such a situation would be ridiculous (eg. the 16 ways of
writing my name) and, in some cases, frightening.

Some people are trying to use this feature of English to claim that they
are not subject to the US income tax.

Is it to avoid having to think up new identifiers? And how would you
distinguish case when reading out bits of code over the phone for
example?

You don't read out bits of code over the phone. If you ever read out
*passwords* over the phone, you can take a long time doing it, and it's
still horribly error-prone. ("Upper case B as in Bastard, open square
bracket, control lowercase R as in Retard, digit nine, ....")

Some case-related questions for Standard C:

What is the maximum number of cases allowed? What is the maximum
number of cases actually implemented in a locale for a real language?
(e.g. Tholian doesn't count. Klingon might as some people have
tried to flesh it out as a complete language. Real human languages
count, even ones that are dead like ancient Egyptian.)


Is it permissible in a standard C implementation that (where c is a char)
c != toupper(c) for all values of c where isalpha(c) != 0,
c != tolower(c) for all values of c where isalpha(c) != 0,
and c == toupper(toupper(toupper(c))) for all values of c where isalpha(c) != 0?

(in other words: there's three cases, toupper() does a "circular
right rotate case", and tolower() does a "circular left rotate
case". There's no "uppermost case" or "lowermost case".)

 

[Flash Gordon]

Malcolm McLean wrote, On 19/07/07 22:34:

If a function does no IO then there is no reason for it to call any
platform-specific functions, except very rarely when for efficiency
reasons a calculation cannot be coded in C. So separate your functions
from your procedures, and the situation cannot arise.

What does separating functions and procedures have to do with it? Apart
from implying you are using the term function in a non-C way which means
you should have stated that up front if you want to be understood.

Unfortunately reality sometimes kicks in. For instance a lot of long
procedures work fine in development, but for commercial use they need to
support progress bars and user cancels. Error conditions can also be a
problem, as can dependencies on big datasets. Generally however the
system works.

If you think any of the above don't come in to play in development then
you should not be involved in SW development, since everything you
mention should have been in the requirements and design before you even
consider starting your source code editor.

Then of course the standard does provide methods for basic IO, which can
break.

Anyone with any knowledge knows that any IO operation can fail. This is
why where it is really critical you have multiple physical IO paths. So
of course the standard C IO functions can fail.

 

[santosh]

[ ... ]

Not entirely true either... The Romans and Greeks lived in
case-insensitive worlds.

Yeah I know, as is my native language, but I was talking about
English, since it comes closest to a global language, if there ever
was one.

 

[Richard Heathfield]

Gordon Burditt said:

You don't read out bits of code over the phone.

Well, maybe *you* don't. I have done so on several occasions.

 

[Mark McIntyre]

The first computers *you* worked with... In 1965 Ascii was standardized
for the second time and that version had lower case letters.

Quite possibly. However the terminals (?VT52 and Tek4100?) on our Vax
cluster didn't provide any trivial way to enter lower case, and
neither VMS nor Fortran gave a hoot anyway.....

they could certainly be displayed on the terminals
when they were tube terminals.

The keyboards I used in Oxford in the early *eighties* didn't even
HAVE lowercase letters on the keyboards - and the teletype paper only
printed Ucase anyway....

But the actual question is easy to answer. C ultimately derives from
Algol, and that was case sensitive.


F66 derives from a much older language, and I think that even F66 allows
both cases in strings.

Yes, thats true. As far as I recall F66 required all code to be
uppercase. I recall being very happy when we got an upgrade which
allowed mixed case because by that time most of my coding was done via
a terminal emulator running on a Sun-1 or PCXT which of course /did/
have mixed case...
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Malcolm McLean]

If you think any of the above don't come in to play in development then
you should not be involved in SW development, since everything you mention
should have been in the requirements and design before you even consider
starting your source code editor.

If you program business logic then you have requirements and design. If you
are doing scientific programming then the interest is in proving the
algorithm. So you are not interested in UI issues, only if the general
approach works. However eventually the function will have to be packaged for
a non-programming user.

 

[Flash Gordon]

Malcolm McLean wrote, On 20/07/07 21:44:

"Flash Gordon" <[email protected]> wrote in message

Please don't snip attributes for still included text. You wrote the below.

If you program business logic then you have requirements and design. If
you are doing scientific programming

Then you also have requirements (or you are not required to write the
code), and the code still needs to be designed.

> then the interest is in proving the
algorithm. So you are not interested in UI issues, only if the general
approach works. However eventually the function will have to be packaged
for a non-programming user.

So you design it to be able to but in a fancier user interface. It's
what is called designing for expected extensions and saves a lot of work.

In any case, you *still* need to handle errors, because if you don't you
don't know if the results you get are due to uncaught errors or not.

 

[Malcolm McLean]

Then you also have requirements (or you are not required to write the
code), and the code still needs to be designed.

It doesn't work like that.
I've had this before from people who work in businessy type systems and
think that games can be formally specified using the same techniques. They
can't and no games company does that, for lots of reasons. One is that no
one cares if output is correct, just whether it plays. Another is that you
don't know how well the program is going to perform until it is in quite an
advanced stage of development, at which point you decide how much geometry
to throw at the rasteriser.
Scientific programming is a bit different to games, but again you can't
generally specify the program and then write it. If you can do that then
it's not reasearch.

 

[Ian Collins]

Malcolm McLean wrote, On 20/07/07 21:44:

Please don't snip attributes for still included text. You wrote the below.


Then you also have requirements (or you are not required to write the
code), and the code still needs to be designed.

But the design may be done in code...