naming conventions, was: Case sensitivity



I've been following the discussion as something of an outsider -- a
Lisp implementor rather than a real Maxima user -- but I want to bring
up an issue everyone has been missing in the tangle surrounding case
sensitivity: I18N.

It is more and more common for language implementations to support
I18N characters, typically in Unicode.  Some Lisps do already, and
Java has used Unicode (usually encoded externally in UTF-8) from the
outset.  (FSF Emacs also does, except that Mule encoding has some
minor differences from Unicode.)  Memory and transfer bandwidth
continues to cheapen, so it is clear that over time more and more of
the computing universe will support 16-bit Unicode or better.  Maxima
should not make decisions now without thinking what typical
applications will look like in ten years, or else the solution won't
last.  Non-Emglish speakers should be able to name their variables
with native words.  I've even heard about this obscure tribe of
non-English-speakers called "Mathematicians" who adopted the Greek
alphabet when they need to record their thoughts, and some obscure
sects of Mathematicians have been known to use the distinction between
"small" and "capital" Greek letters.  (Unicode provides for this
distinction.)  Case is not normally used in the CJK languages, but
typographically, there are variants (e.g. the "half-size kana" in
phonetic Japanese) that are considered separate characters.  And (Lord
help us) there are some Eastern-European languages that have _three_
cases: upper, lower, and title.

[This is an extract from an online file describing the downloadable
Unicode database:

  CASE MAPPINGS

  In addition to uppercase and lowercase, because of the inclusion of
  certain composite characters for compatibility, such as "01F1;LATIN
  CAPITAL LETTER DZ", there is a third case, called titlecase, which
  is used where the first character of a word is to be capitalized
  (e.g. UPPERCASE, Titlecase, lowercase). An example of such a
  character is "01F2;LATIN CAPITAL LETTER D WITH SMALL LETTER Z".

]

Now, it would be nice if some day Maxima users on capable platforms
could use Greek and their native language without prejudice.  Of
course, for the forseeable future internal modules and library code
should be restricted to ascii/Latin1, otherwise some platforms won't
even be able to read it, much less compile and run it.  But that
restriction shouldn't unnecessarily extend to what the end user types
into his Maxima command loop, or into the application files he writes.
If it cannot do so already (on a I18N-capable platform) little would
be necessary to make Maxima capable of full Unicode support.
Therefore, language designers should not think about case just in the
context of the Latin1 character set.

Now, the proposals that Maxima be case-insensitive have a built-in and
IMO unwise assumption about the I18N capabilities of the underlying
Lisp implementation.  This is entirely homologous to the similar
discussions abot case sensitivity in the Lisp community.  Most
case-insensitive implementations treat car and CAR as the same
symbols, but treat upper-case-lambda and lower-case-lambda as distinct
characters, as well as the odd case-like character equivalences of
Near-Eastern, Far-Eastern, and Hyper-Eastern languages.

Implementationally there is a good reason for this.  It is
straightworward for the Lisp or Maxima implementation to add a little
reader code to fold the 26 Latin1 letters into a single case.  It is
hugely difficult to do the same thing for the entire set of Unicode,
which aside from being a moving target, also embodies the risk of
violating incomprehensible non-Northern-European cultural
expectations.  It leads to a language that considers X and x to be the
same, but insists that upper-case-lambda and lower-case-lambda are
different.  This bothers me as inconsistent and surprising to
non-ISO8859-1 speakers.

Therefore I suggest that any future language, in which the end-user
programmer can invent variable names of his own choice, should be case
sensitive, if only for consistency with I18N text.

[Editorial note: The above was mostly serious.  What follows is not.]

Anyone who still doesn't think that case matters is invited to view
the following web page, which shows how functional calculus can
diverge when case is ignored.  It contains two nearly-identical
images, unretouched, that I found in separate places on the internet:

http://www.franz.com/~smh/nlambda.html