Re: Casifying at output time doesn't win...

[Kent M. Pitman <KMP at MIT-MC>]

The following case comes up every time we have had to discuss this in GRINDEF
bug mail. I don't think the I/O scenario you described will handle it...
Consider:

  (PRINT (READ))(X x |X| |x|)

then,

  X must be EQ to |X|
  x must be EQ to |x|

|X| must have a print property that says he needs vbars (or equiv) on output.
 X  must have a print property that says he accepts the default case.
|x| must have a print property that says he needs vbars (or equiv) on output.
 x  must have a print property that says he accepts the default case.

Actually, only 3 of the last 4 statements may need to hold at any given time.
The first two are not jointly satisfiable, however, since the symbols are eq.
The second two likewise. Hence, I don't see how you can make output do the
right thing as you describe.

The problem is harder for multi-character symbols.

I don't think your scheme would hold up. If indeed it would, I would like to
hear further details.

I continue to uphold that case translation unless specifically requested a la
/ or |...| should be done. The fact that Lisp happens to translate to uppercase
rather than lowercase is probably unfortunate. But the fact that it translates
is NOT unfortunate. It is quite definitely a useful and comfortable feature.