Re: Issue: READ-CASE-SENSITIVITY (Version 1)

[peck@Sun.COM]

Some random thoughts on READ-CASE-SENSITIVITY.

First let's remember that we're not asking for more functionality,
in this issue, we're looking for a way to make READ do *less*.
In the naive world, strings would read as they were written,
and, oops, symbols naively interned would choke on mixed case.

Two alternatives have been mentioned so far:
  1. Change the code in READ to not coerce to uppercase (controlled somehow)
  2. Use *readtable* to produce the new effect.
 There is another possible solution:
  3. Introduce a new function to provide what you want.

Kent states that the status quo was done so that programs would
be more portable (or portable at all) among uppercase source
and lower or mixed case source files.

Kent further suggests that using *readtable* would be an appropriate way 
to avoid upcasing.  [if using readtables to control casing behavior is so
straight forward, why was the status quo implemented as a change to READ,
rather that as a change to *readtable*?  ;-]
  [[no flames please, I answer this for myself three paragraphs down...]]

Plenty of discussion about the danger of reading code when *read-base* or
*readtable* is set inappropriately.  Also, plenty of discussion that
PROVIDE/REQUIRE don't port. Really, portable code should come with
its own loader which rebinds reader controls and loads its files as needed.


Dalton states:

>There are a number of applications that could make good use of the
>Common Lisp reader except for one thing: the reader does not preserve
>case.  I would like to help these applications.  In addition,
>						  â??â??â??â??â??â??â??â??â??â??â??
>programmers who wanted to wanted to use case distinctions in code
>would find it easier to do so.  You can regard this as an application
>if you wish: there is a language very like Common Lisp only...

I'm all for mixed/lower case (I like Franz's  solution) but let's face it:
*** READ is designed for reading programs (symbols, lists, structs, etc). ***
It sounds like you are not primarily concerned with wanting
"to use case distinctions in code". So, READ should not be changed.


Dalton, about these large bodies of code which could use READ, except
for the caseing behavior:  can they survive what READ will do with
chars like #\# #\: #\\ #\| #\` #\( #\) when they are read?

If you are not using READ for code or symbol and package rules,
the what do you get from READ?  the *readtable*?

To read text you really need to use READ-CHAR or READ-LINE.
Even if READ can be used, is it really a good idea? Do you really want 
to cons a symbol for everything that READ would break into a token?

Maybe you should suggest a READ-TOKEN or READ-SYMBOL function
that parses like READ (if your really want that) and returns
a symbol (interned where?) or maybe just a READ-WORD that
does READ-CHAR up to the next whitespace and interns the string?

Given READ-LINE and READ-CHAR and the multiple interpretations of
what and when should you break symbols out of text, why/how should 
this be standardized?  

[Better Lisp environments come with an Emacs (or whatever), that
 is maybe the correct place for text processing Upcase/mixed-case
 word parsing, etc.]


Whatever we decide about this, lets make sure it makes sense with the
newly proposed internationalize character operations.