Conference turris::languages

	That case-sensitive Pascal is a no-no, simply because Pascal isn't
supposed to be case-sensitive...

	As for the general issue, I prefer the following:  Identigiers should
be case-sensitive, but keywords shouldn't.
	I prefer lowercase keywords, but I really don't want to impose that
preference on anyone else.  Fortunately my language of choice - C - uses
lowercase keywords.
	But case-sensitive identifiers are a great idea.  Why?  I've seen too
many programs whose authors can't make up their minds what style they're coding
in.  It's FOO in one place, foo in another, etc...  People like that deserve to
have compilers yelling at them!
	On the other hand, a real idiot could use FOO, FOo, FoO, Foo, fOO, fOf,
foF, and foo in the same program...
		<_Jym_>

Jym,

    I think you and I mean different things by the terms 'case-sensitive' and 
'case-insensitive'.  As I understand it, a language is case-insensitive for, 
say identifiers, if it accepts 'FOO', 'Foo', 'foo', etc. as all meaning the 
same thing.  A language is case sensitive when it "cares" how you enter 
things.

    I prefer case-insensitivity for both identifiers and for key words.  I 
like write in lower case, but capitalize initial letters of statements and 
things which look like proper nouns to me.


Dave C.

  Another vote against case-sensitivity.  Two reasons:

	1) It's yet another way to put errors into a program.  Case
	   errors are hard to find just by looking at the code.

	2) All programmers have their own style.  Case sensitivity locks
	   all the programmers on a development team into a particular
	   style of capitalization, like it or not.

  -- Bill B.

Another factor to be taken in to account by the language implementors in the
clever way DEC sales reps found to save a hundred bucks or so a few years ago.

UPPER CASE ONLY LINE PRINTERS

YES THERE ARE THOUSANDS AND THOUSANDS OF LINE PRINTERS OUT THERE THAT CAN'T
BE USED FOR APPLICATIONS WHERE case is significant.

And until we really create an awareness that customers need UC/lc capability
we ought to be careful about making case important.

Pat Sweeney

re: .-1

Well, here's a great opportunitiy to make some of those tight-wad customers
cough up another couple hunderd bucks!  <insert profuse smiley faces here>

I think case sensitivity is just another idea, and ought to be tried out, but
I don't want to see it implemented in production compilers until then.  I
sometimes use upper/lower case in a single variable name because I'm a touch
typist, and don't like to go searching for the underscore key.  So instead of
KEY_SWITCH or key_switch I'll use KeySwitch.

There's always a new 'coming thing' in compiler development.  I remember a
few years back a report that demonstrated that indentation was exactly 
equivalent to begin-end blocks.  At that time the coming thing was to make
indentation lexically and syntactically significant. Whatever happened to
that idea?  I liked that one much better than case sensitivity.

Don.

If a case-sensitive language or linker or ... does name matching, then in cases
would otherwise cause an error if a name isn't found or defined, it should then
attempt recovery with a case- or case-and-diacritical-insensitive name match.

A flame(r) for sure;

 Except for case checking in a variable string of what use is it to have case
sensitivity? How often are you likely to use the same variable name and
differentiate it by case only? I use C and find it a piss ant language
because of the case sensitivity. It makes error chasing REAL hard when you
have only an uppercase line printer(this is a problem at BOTH your local dec
office and on-site at a customer).
 If you want case sensitivity then put in a /check_case compiler switch,
don't jam it down my throat. If you can't type a program correctly then you
shouldn't be doing programming of a product that needs maintenance. 
 The problem comes from people who think Unix is a great language when in
fact it is mediocre at best. The stupid o.s. case checks because C case checks,
a real catch-22.
 I only want to check case on an input variable string.

out of kerosene, flame out.

I also vote for case-insensative compilers.  In school we had this wonderful
pretty-printer for our Pascal programs that would make all Pascal keywords
uppercase and identifiers lowercase.  It really made the keywords stand out,
so I adopted that as "my" style.

When I went to write my first-ever C program, I naturally put all of the
keywords in uppercase.  Needless to say, the compiler couldn't figure out
what to do with my source file.

The justification of case-sensativity of giving you more possible variable
names sounds like:
	a) the compiler writters were too lazy to add the code to
    convert the input to uppercase.
	b) taking a bug and dressing up in a three piece suit.
	c) some sadist is into watching people chase bugs when
    EOF <> eof <> Eof <> ...

Chose one of the above.

	- Barry

a) It wasn't "the compiler writers", it was the compiler writer.

The best argument FOR case sensitivity is that the letters look
different.  'a' doesn't look like 'A' and shouldn't be treated
the same way.

The "sadist who is into watching people chase bugs when EOF <> eof
<> Eof <> ..." is the person who put a global "eof" into the
RSX system library which causes your task build to fail if
you have a global of the same name.

Somehow, I don't think we come to this argument with our hands clean.

Martin.

re .-1

I think the problem with the names that go in system libraries has more
to do with a feature lacking in almost all compilers, the ability to
reference a name that isn't (and/or can't) be valid in the lanugauge
yet that might be valid in the environment that the compiler runs in.

A system might reserve a set of characters to be used by DEC and not
customers, for example, . and $.  Fine, a user knows that he shouldn't
use those characters.  So now all the system library routines include
one of these characters, except now nothing can reference them.  FORTRAN
was THE language when RSX was developed, so library routines that FORTRAN
can call were included in the system library.  Now this means that these
library routines might satisfy a request unintentionally if the user makes
the error of not defining this symbol.

After these mistakes were made, C comes into being.  What does it do ?
Almost everything is done with common library routines, like I/O with
plainjane names.  At least the FORTRAN ots routines were concealed with
names that couldn't conflict with any user defined FORTRAN name.  If I
write a routine named read, but forget to include it when linking my
program, I'm going to get some stupid routine that does entirely the
wrong thing.  Why wasn't it named uni*read or something ?  The problem
here is that a name was chosen that can't easily be differentiated in
common use.  The "system" has to deal with that problem, because to
require the user to do so, places a small burden on a very large group
instead of placing a relatively larger burden on a much, much smaller group.

A lot of people know me as "mulp", spelled like its pronounced.  I used
to write it as MuLP to echo its origins: Michael Lee Pettengill: MLP.
Its a long story, but from my initials I came to be called mulp, which
I wrote as MuLP, but some people write as Mulp since they think that its
just a strange name when they hear it.  Now I don't expect VMS to know
about names, initials, and folklore, so I think its reasonable for it
to call me MULP and to force everyone else to do so as well when they
ask VMS to contact me.  There's only one mulp (as far as I know) and
since no one gets confused about that even if I'm referred to as Mulp
or MuLP or MULP, I don't think that a compiler or larger system should
get confused.

mulp

It is desirable that all project members use exactly the same style (look) in
their code.  Uniformily styled code is far less demanding to read than code
in mixed styles.  Although Ada is insensitive, Ada style should be uniform to
enhance maintainibility.  Intellimac, 6001 Montrose Rd., Rockville, MD  20852,
published an Ada style manual, taken from government-sponsored examples.
In this document, case is mandanted for all possible characters except 
comments.  To wit:

A. The first letter of each part of an identifier must be capitalized.
	Size_Of_File
B. Unless it is a loop index, which may be uncapitalized.
	for i in 1...10 loop
C. All letters of the name of a block or loop must be capped.
MAIN:
loop
.
.
end loop MAIN;
D. IN and OUT indicating a parameter mode must be in all caps.
E. RETURN (in a return statement), EXIT, and RAISE must be in all caps.
F.  No other letters may be capitalized.
I was taught to all-capitalize keywords in PASCAL, and 
initial capitalize identifiers, and I believe this enhances the visual acuity 
of the code.
TOm

MuLP is quite right in blaming C for plain-jane names.  I think that
C will "drift" towards reserving the majority of the library names
(as did Fortran).  If this is done, the compiler is free to translate,
say, read() to C$READ(), eliminating the problem.   (The compiler
would also be free to expand routines in-line, speeding up string
operations noticably).

In case anybody's interested, I wrote a C style document which may
be copied from REX::DECUS$LIBRARY:CSTYLE.*

It follows the Bell-Labs (Kernighan and Ritchie) style very closely.

Martin.

  RE: .11

  I agree that the programmers on a project should adopt a common style,
  but it has been my experience that at DEC any project leader trying to
  enforce such rigid capitalization rules will simply get laughed at.

  You can't enforce style -- at least not here, where software engineers
  are hired for their leadership potential and are generally strong-willed.

  -- Bill B.

Not only is C case sensitive, but so if I remember rightly is Unix !

re: Style.

Note that there's coding style, and there's formatting style.

Although it's useful for members of a project to have similar formatting styles,
they needn't be identical.  In fact, when tracking problems, I've occasionally
been pleased to identify the person responsible for a small section of code,
based on subtle differences in formatting styles.

Coding styles seem to be differentiable at 'twenty paces'.  If differences in
formatting style are subtle, but recognizable by the team members, it probably
means they're doing a good job with code reviews.

Some of these rants against case-sensitivity are so silly, I hardly
know where to begin.  So this list is in pretty random order.

   1)	"But case sensitivity forces the same capitalization conventions
	on every project member!"  Bravo.  It is quite unprofessional to
	perversely choose a coding style different from the rest of your
	project just to assert your individuality.  Once a coding style
	has been agreed to for a project, it should be adhered to.

   2)	"It's just another way to introduce errors."  Errors, yes.  Bugs,
	no.  Case typos will be caught at compile or link time.

   3)	"The compiler writers were too lazy..."   Unix started out on
	small, slow machines.  It was purposely coded as leanly as possible.
	Among other things, this means not converting everything to upper
	(or lower) case before doing comparisons.  I don't know if anyone's
	ever done any measurements, but Unix machines have saved millions
	of cycles in NOT converting the case of identifiers, filenames,
	and commands.

   4)	Preserving case is a good way to distinguish different classes
	of identifiers.  For instance, in Unix-land it's common to name
	most files with lowercase names, but to start names of important
	(Read-me) or distinguished (Makefile) files with an uppercase
	letter.  That way they all come out first in a directory listing
	(or cross reference listing, or symbol table) before all the
	lowercase identifiers.

   5)	"It's just another newfangled fad which will pass..."  The C language,
	and Unix, have been case-sensitive since their inception around 1971.
	Modula-2, which is bound to become an extremely important language
	(more so than Pascal, APL, or Bliss, I'll wager) is case sensitive.
	Prolog is case-sensitive (atoms start in lowercase, variables in
	uppercase).  Smalltalk is case sensitive, the convention being that
	classnames are capitalized while variable names are not.  LISP is
	case sensitive (although it ordinarily uppercases identifiers you
	type in, so you have to quote them to get lowercase into them).

	So...  even if you don't like case-sensitivity, you'd better design
	it into your linker, debugger, cross referencer, etc. etc. or you're
	going to find it pretty hard to support five very important languages.

- Larry Campbell

re .-1

I suppose it depends on how one defines a project.  Does writing in xYz
require that the entire system be written in xYz, and not xyZ or Xyz ?
Probably so.  No one could conceivably written anything of interest or use
in a language like FORTRAN, BLISS, or Pascal, right ?

Note that it is FORTRAN not Fortran or fortran, but its Pascal not PASCAL
or pascal.  Why ?  And how does a librarian alphabetize ?  By very complex
rules that would place fortran, Fortran, and FORTRAN together.  Why ?
In the former case a set of rules and conventions apply that determine
the proper representation of a name.  In the latter case, the rules used
reflect the equivalence of upper and lowercase letters (among others).

If I cared about saving machine cycles, then I'd use binary to code.
What a waste to spend time using a machine to translate commands from
an abstract representation to binary.  Nothing personal, but I can't
believe that anyone would use that kind of argument.  If anything,
distinguishing lowercase from uppercase should require many more
cycles in a well designed system.  Either every name must be declared
prior to use or the automatic declaration of names must check for possible
case confusion.  Or the editors used to create the source should prevent
improper use of capitals.

Of course this is a ridiculous discussion, but there are ridiculous ideas
about how a language should be designed.  One of the most common ideas
is that this is the first and last language of importance and so it doesn't
need to consider any other language system.  If you want truely ridiculous,
how about the coding convention for RSX:  EVERYTHING IN CAPITALS INCLUDING
ALL COMMENTS BECAUSE EVERYTHING IS IN CAPITALS BECAUSE VT05S DIDN'T HAVE
LOWERCASE AND DAVE DIDN'T WANT TO WASTE TIME USING THE SHIFT KEY.

Re .16:

I have things to say about several of your points, but I would like to
emphasize right now that I don't care if Unix systems throughout the world
save a cumulative total of 10 11/780's worth of computes every second if
it means *I* have to retype my last command because the caps lock key
was down while I was typing to the shell.  My share of all the computes
saved by case-sensitive text processing is worth NOTHING compared to
being able to type in to the shell without having to worry which case
it is in.  My time is more important than the computer's.
				/AHM

  RE: .16

  "errors, not bugs"

  If by mistake one assigns to variable x instead of variable X (where
  both have been declared), how can this be detected at compile-time?

  LISP:

  "Any uppercase letters that appear in the ... name may be written in
  either case ... For example:

	FROBBOZ		; The symbol whose name is FROBBOZ
	frobboz		; Another way to notate the same symbol
	fRobBoz		; Yet another way to notate it"

  (From COMMON LISP: THE LANGUAGE by Guy L. Steele, Jr. Copyright 1984 by
   Digital Equipment Corporation.)

  Sounds case-insensitive to me.

  -- Bill B.

Re .-1:

It's true that if you name two different variables x and X, you'll
get into trouble that the compiler won't detect.  You'd also deserve
it.  In case-insensitive language, you wouldn't (I hope!) name two
different variables "RECORD-POINTER" and "RECORD-PTR", for instance...
variable names that are too close are dangerous regardless of case.

As far as LISP goes, the example you mentioned works only because
the reader ordinarily converts lowercase typein to uppercase.  If you
read a bit further down the page in the Common LISP book, you'll see
that you can prevent this uppercasing by quoting the lowercase characters
with \, or by quoting the entire symbol name with |.  So although
you have to a bit out of your way to do it, LISP can be case-sensitive.

Having said all this, I'd like to add that case-sensitivity is one
of the LEAST important problems facing language designers today.
The subject obviously has a high flame value, but that's about all.
Why not complain about IMPORTANT things, like subclassing?  Concurrency?
Overloading?  Information hiding?  etc. etc.

It is important to complain about it because if you can't get the little
things right, you will probably not much do better with the big picture.

The next thing I expect to hear is someone saying that PointerToFooBar
is more readable than POINTER_TO_FOO_BAR (or pointer_to_foo_bar or
Pointer_To_Foo_Bar), and that underscore shouldn't be wasted on trivial
lexical issues when it can be used for a vital masking operation needed
for placing underscores in string variables.  They both make the same
sense for algorithmic languages (none).
				/AHM

  RE: .20

  With regard to LISP, you seem have your own idea about what makes a language
  case-sensitive.  The fact that by using some fancy quoting notation you can
  put lower case letters into the compiler's symbol table IS NOT RELEVANT.  In
  BLISS, you can do it with the %NAME construct.  Irrelevant.  The fact that
  foo, FOO, Foo, FOo, etc. all refer to the same variable makes the language
  case-insensitive.

  With regard to the naming of variables, RECORD-POINTER and RECORD-PTR are
  much more different than x and X.  One would hope that in both cases the
  programmer would have the good taste not to declare the pair, but, as I
  said, you can't dictate good style.

  -- Bill B.

(1)  Try reading the following over the phone:

	if Xalpha > XBETA then XALPHA = Xbeta;

     Irrelevant?  Not if, like many of us, you record code sequences
     aurally rather than visually.  I believe that a sequence of letters
     denotes a word (natural language usage), whatever the usage of that
     word in its computer context, and a word is primarily a *speakable*
     entity.  We do not remember case information when we remember words --
     we have simple rules for regenerating it.  (Apply the phone test
     again -- do you pronounce "XPTR" as "X" "P" "T" "R", or as "X"
     "POINTER"?)

(2)  Which brings us to the second point.  I hear, over and over again,
     the claim that XALPHA vs Xalpha vs xAlpha is a red herring -- that
     no sane programmer would ever do such a thing.  I hope that that's
     true, but if it is, why does the compiler need to be case-sensitive?
     Coding in Pascal, I can write my constants as LETTERA, LETTERB, etc.,
     my types as Real, Integer, ValueRange, etc., and my variables as
     thisRecord, i, real1, etc., if I feel like it.  Why get the compiler
     involved?

In short, I claim that if case differences are just being used as a kind
of visual comment to convey usage information to the reader, the compiler
doesn't need to get involved; and if the compiler does need to discriminate
between names based on case, then something is wrong with the program (or
the language).

	-Neil Faiman

if you want to be able to declare 'x' and 'X' as different things, then 
*PLEASE* can the compiler flag a warning error (which I can ignore, but 
it will prevent me doing it by accident) ?

	I've just seen some code that does something gross.
	VMS used qualifiers (/ENGLISH_WORD) while Unix uses flags (-x, where
x is a single letter).  The single letter is usually the first letter of a
word.  If they have to handle two actions that start with the same letter
(/OUTPUT and /OBJECT, for example), one of them is uppercased (-o and -O).
	Well, I just saw some code that worked off of that.  If the user
specifies -o, it sets a variable called "oflag".  If the user specifies
-O, it sets a variable called "Oflag".  How disgusting!
		<_Jym_>

Unix (and C) are perfectly logical and consistant in their use
of case.  The cases are different.  Calling the two flags
oflag and Oflag seems perfectly logical to me, given the particular
circumstance.  I'm much more worried about people who use 'l' where
they mean '1' or 'O' where they mean '0'.

(My programs almost always map the case of flags, but one often
must work with existing code and operating system design.  For
example, the Unix C compiler uses '-o file' to name the output
file, and '-O' to signal "optimize".  To me, this is less annoying
than the pain one must go through on VMS to pass a lower-case
string through the command processor.)

Martin.

I don't suppose you considered more obscure names like optflg and objflg
or optimize and object_file?

I assume this is a good example of how language affects thought processes.
				/AHM

Of course I didn't change the commands -- they were GIVEN as part
of the operating system (Unix).  Arbitrarily changing them would
make it difficult to share my work.  (Ever type at a collegues
terminal using his Emacs/EDT bindings which, of course, are different
from yours?)

-o and -O look different and aren't that hard to keep apart.  Much
easier than "assign" and "define" on VMS.

Martin.

Who asked you to change the names of commands or switches?  I want to know
whether writing code with variable names like oflag and Oflag is supposed
to be smashing good taste in the C/Unix user community.
				/AHM

  I feel compelled to point out that -o and -O don't look all that different
  on equipment such as the VT05.

  The real Unix crock, of course, is that silly restriction which limits
  switches to be only one character long.

  -- Bill B.

Look at "find" on Unix.  It has multiple character switch names.  And is
a glaring exception.
				/AHM

Actually, Unix does a better job of fallback on VT05's than our
operating systems.  If your login name is in tasteless uppercase,
it assumes an old-fashioned terminal and quotes all lowercase
letters by preceeding them with ' -- you can also type both
cases from an uppercase only terminal.

If you really still have a vt05, you might consider donating it
to a museum, not use it as an absolute restriction on operating
system design.  We stopped making them about 10 years ago.

Martin.