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

[cutting.pa@Xerox.COM]

  Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanupâ??.pa
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 15 FEB 89
13:31:21 PST
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
SAIL.Stanford.EDU with TCP; 15 Feb 89  13:31:01 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 539857; Wed
15-Feb-89 16:28:54 EST
Date: Wed, 15 Feb 89 16:28 EST
  From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

  *PRINT-CASE* was very carefully chosen after a -huge- amount of
  discussion to permit flexibility -without- affecting the semantic
  correctness of code. That is, if you set *PRINT-CASE* globally, you
  don't interfere with the correct operation of libraries that others
  have written, regardless of whether their original program or
  runtime data is uppercase, lowercase, or mixed case. 

  On the other hand, your proposed *READ-CASE* does not have this property.
  You could not set it reliably because you would never know when some
  macro or some data-manipulating utility would call something like
  READ-FROM-STRING behind your back and get screwed because you'd changed
  the semantics of that operation. It would therefore not contribute to
  modularity.

How is *READ-CASE* any different than *PACKAGE*, *READ-BASE* and
*READTABLE* in this respect?  They all change the semantics of
READ-FROM-STRING, occasionally even screwing things up.  There is
precedent.