Re: but you're losing flexibility...

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

    Date: 02/02/81 07:00:07
    From: RMS at MIT-AI
    To:   KMP, LISP-FORUM
    Re:   Casifying at output time wins for what I want it to do.

       Date: 1 February 1981 22:28-EST
       From: Kent M. Pitman <KMP at MIT-MC>
       Subject:  Casifying at output time doesn't win...
       To: RMS at MIT-MC

       Consider: (PRINT (READ))(X x |X| |x|)

       then, X must be EQ to |X|
             x must be EQ to |x|

    At this point my actual idea and your idea of my idea part company.
    You seem to think I am trying to arrange for each use of the symbol X
    to print out the way it was typed in.  I'm not.  I certainly want both
    x and X to turn into |X|, always, and both of them would print out the
    same.  The question is, do they both print out as X or both print out
    as x?  This is what I would like the user to be able to specify.

The point here is that suppose that in one critical piece of code, the guy
had *really* and *truly* wanted to force uppercase "TOGETHER" to be the way
the symbol was cased on input and output. He couldn't do it. He would write
(defun f (|TOGETHER|) ...)
and his output would come out "(defun f (Together) ...)" or 
"(defun f (ToGetHer) ...)" but his output stream handler would have no way
of allowing him variation of case. One would rarely want such, but if he did,
your algorithm doesn't seem to provide for it ... I take it that what you
are saying though, is that if he wants this sort of thing, he should be 
willing to pay this price.

    Anyway, I'm really quite satisfied with the way Maclisp works now.

I'm glad of this. So am I. The above discussion is not really so much for
your benefit as for the benefit of those who haven't thought as much about
this.