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

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Thu, 16 Feb 89 15:41:29 GMT
    From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>

    ... Right now I can change the operations of READ in lots of ways, by
    setting the input base, by defining macro characters, and so on.  I
    don't see why a simple thing like case sensitivity is such a problem. ...

Actually, this makes me all the more certain that the readtable is the
right way to go. The reason is that you can imagine a world in which I
have hacked the readtable to get me case sensitivity but you have bound
*READ-CASE* to ignore case sensitivity. This is something of an invincible
force and an impentrable barrier problem -- two conflicting goals using
orthogonal mechanisms such that it's impossible to weigh their importance
adequately. By forcing us to use the same mechanism, we see that we either
use your readtable or mine, or that both readtables are the same and you've
mucked up mine or I've mucked up yours. This reduces the problem from one
of the system trying to arbitrate a situation it cannot hope to settle fairly
to a simple program bug -- one or the other of us will send nasty mail to
the other and the system won't be caught in the middle.

By the way, as a slightly tangential remark, I think that *READTABLE* is
misnamed. I really think it should be called *SYNTAX*, or perhaps even
*LANGUAGE*.  The reason is that the printer needs to be affected in
lockstep when you bind the reader in order to preserve PRINT/READ
consistency. So if I change my backslash character to slash in Symbolics
Common Lisp, the printer must know to write /a rather than \a. Calling
it *SYNTAX* would divorce you from the idea of READ-only effects, since
syntax can address printing as well. Once you study the issue a bit
more, you realize there are other dynamic properties of a language
which it is -also- useful to bind when running programs from one or
the other language which have nothing to do with PRINT/READ. If you
allow them to be bound separately, you get in weird situations where
you have hybrid environments that have `Common Lisp syntax' but
`the Zetalisp package system' but ... Almost never do these things turn
out to be useful. Usually they are the result of binding too few variables
in lockstep. If *SYNTAX* were further generalized to encompass non-
print-read kinds of things, you might call it *LANGUAGE*. By having a
single variable, it would always get bound consistently. (If you really
still wanted a new language, you could make a new object which had the
same blends of things, but you could not do it by accidentally binding
one too few variables.)

    ... At some times, it seems that you hate every aspect of the
    proposal, but at others that all you really dislike is the the
    addition of a new parameter (admittedly a problem that is not just
    aesthetic) and the particular keyword values I propose.

People are complex entities. They must weigh the realities of the world,
which are rarely black and white. My message may have drifted back and
forth but was intended to expose the basis for my reasoning, which I must
ultimately boil down to a single recommendation. If I choose to say just
my opinion, you'd think me stubbornly dogmatic. At least with the additional
information you know I've given the issue some thought.

    ... I had to pick one of the many possible proposals as a
    starting point ...

I'm glad you did. If you're happy with the readtable solution, I think
there's a good chance you'll come up with something I can endorse.
I thought more about the analogy to adding special forms last night
and decided that the analogy is slightly misaligned -- the real truth
is that the `fixed number of special forms' only affects people writing
code-walkers. Adding special forms isn't so good, but affects only a 
few programs. Adding a new variable of this type would break a huge number
of Common Lisp programs because a huge number call READ and because
CL programs are assumed to `act defensively' (bind variables they worry
might be wrong). Since no existing program can have anticipated the need
to defend itself against this `problem,' no program will be ready and
the Cost To Users is (as I said) large. I think this consideration has
to be overriding.

I admit that if we were starting anew, compatibility would not be an
issue and I could not argue against *READ-CASE* on the basis of compatibilty.
But if we were really starting anew, I would argue for *SYNTAX* or
*LANGUAGE* in order to accomodate the bundling of linguistic features
as a unit. And READ-CASE then would be likely be a slot in that structure,
just as it's conceptually a slot in your `frame' for computer languages
in general. And I would argue that you should not set the slot, or any slot,
because changing any named language only gratuitously breaks those programs
which thought they knew what the semantics were at the time when they wrote
them. There's never really any problem about just spawning a new language
because no matter what syntax/semantics you give it, you never break programs
in other languages.

I'll stop here before I start to question why we're changing a single letter
of CLtL in order to produce ANSI CL and to ask why we don't just call the
language we're designing something else so we don't break programs... :-)