Issue: READ-CASE-SENSITIVITY (Version 3)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 16 Jun 89 19:35:44 BST
    From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>

    I am not going to be able to come to the meeting but would
    still like to see this issue considered.  I wasn't present
    for the discussion at the last meeting, but my understanding
    is that the committee wanted to see the issue again with
    only a single proposal.  

Yes, a single proposal is much better.  I'd very much like to see
this considered, and a single proposal will make that much easier.

			     Unfortunately, I don't know which
    proposal (keyword or function) most people prefer.

I don't either, but I know that at Symbolics we strongly prefer
the keyword proposal.  Since the discussion section says you prefer
the keyword proposal, perhaps as the author you could use your
discretion to opt for that proposal and send out a version 4
omitting the function proposal and the discussion of the relative
merits of the two proposals.

    It has also been remarked that :INVERT is somewhat strange in that it
    would have Zebra read as zEBRA; and it was suggested that inversion
    should happen only if the entire name were single-case.

    Unfortunately, the processing has to happen a character at a time,
    because READ has to do it only for characters that are not escaped.

I don't believe that the conclusion follows from the premise.

    For example, |zebra| should always read as zebra.
    However, READ has to take escape characters into account (so that,
    for example, |zebra| always reads as zebra), and then it is
    difficult to know what rules to apply to the entire token.
    Moreover, the description of READ in CLtL does not provide a
    convenient place to insert processing of that sort (by the time
    the full token is considered, the escape characters have been
    forgotten).

The parenthesized clause is clearly false, since escapedness is
remembered for purposes of package syntax and number/potential number
syntax.  I believe it would be possible to make :INVERT apply only if
the entire name is single-case.  It remains true that we have to decide
whether "the entire name" includes escaped characters or not (in either
case, only the unescaped characters would be inverted).  The Genera
reader does case processing character at a time, as you outlined, but
could very easily implement :INVERT based on either the escaped
characters or all the characters, so that's an existence proof (hint:
one state in its finite state machine would be split into four states,
depending on whether any letters have been seen so far and on whether
they are all upper case, all lower case, or mixed case).  Unless someone
cleverer than me comes up with an algorithm, it would be necessary to
retain the symbol-name in both inverted and uninverted form until
the entire token has been parsed, but the cost of that is negligible.

I think it would be best to base the decision on only the unescaped
characters.  That just seems more consistent with the rest of the reader.

Can you / will you write a version 4 that contains only the keywords
proposal and that specifies :INVERT to invert case only when all the
unescaped letters are in a single case?