#

## Issue PRINT-CASE-PRINT-ESCAPE-INTERACTION Writeup

    Status: proposal VERTICAL-BAR-RULE-NO-UPCASE passed, Jun 89 X3J13

    Issue:        PRINT-CASE-PRINT-ESCAPE-INTERACTION
    Forum:	      Cleanup
    References:   *PRINT-ESCAPE* (pp370-371), *PRINT-CASE* (pp372), WRITE
    Category:     CLARIFICATION
    Edit history: 26-Jan-89, Version 1 by Pitman

    Problem Description:

      The wording on page 372 of CLtL uses fuzzy terms that make it hard
      to tell if *PRINT-ESCAPE* interacts with *PRINT-CASE*.

      Paragraph 1 of the description of *PRINT-CASE* says "This variable
      controls the case (upper, lower, or mixed) in which to print any
      uppercase characters in the names of symbols when vertical-bar
      syntax is used."

      Paragraph 2 begins with the seemingly unambiguous statement "Lowercase
      characters in the internal print name are always printed in lowercase"
      but then goes on to muddy the water by saying "and are preceded by
      a single escape character or enclosed by multiple escape characters".
      This escaping presumably only happens in *PRINT-ESCAPE* T mode, which
      leads one to wonder if other parts of the *PRINT-ESCAPE* description are
      implicitly controlled by *PRINT-ESCAPE* as well.

      The function WRITE is affected by implication.

    Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:LIKE-PRIN1):

      Define that *PRINT-CASE* cases characters the same as PRIN1 would.

    Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:LIKE-WRITE-STRING):

      Define that *PRINT-CASE* has an effect only when *PRINT-ESCAPE* is T.
      When *PRINT-CASE* is NIL, WRITE-STRING is used directly.

    Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:VERTICAL-BAR-RULE-NO-UPCASE):

      Define that *PRINT-CASE* has an effect at all times when *PRINT-ESCAPE*
      is NIL. Define that *PRINT-CASE* also has an effect when *PRINT-ESCAPE*
      is T unless inside an escape context (i.e., unless between vertical bars
      or after a slash). Under no circumstance is any character which was
      lowercase in the internal representation ever presented as uppercase
      due to *PRINT-CASE*.

    Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:VERTICAL-BAR-RULE-PERMIT-UPCASE):

      Like VERTICAL-BAR-RULE-NO-UPCASE, but permit *PRINT-CASE* to upcase
      lowercase characters in the *PRINT-ESCAPE* NIL case since preservation of
      Lisp syntax is not important there.

    Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:EXPLICITLY-VAGUE):

      Specify that the effect of *PRINT-CASE* when *PRINT-ESCAPE* is NIL
      is implementation-dependent.

    Test Case:

      (LET ((RESULT '()) (TABWIDTH 12))
        (DOLIST (SYMBOL '(|x| |FoObAr| |fOo|))
          (LET ((TAB -1))
    	(FORMAT T "~&")
    	(DOLIST (ESCAPE '(T NIL))
    	  (DOLIST (CASE '(:UPCASE :DOWNCASE :CAPITALIZE))
    	    (FORMAT T "~VT" (* (INCF TAB) TABWIDTH))
     	    (WRITE SYMBOL :ESCAPE ESCAPE :CASE CASE))))))

      For each of the following, two clusters of output is shown. The first is
      how an implementation which leans heavily on vertical bars might work.
      The second is how an implementation which leans heavily on slash might
      work. In fact, other interpretations are possible (mixing slash and
      vertical bar). These examples are not an exhaustive analysis of the
      implications of each proposal.

      Possible outputs under LIKE-PRIN1:

      |x|        |x|         |x|         x           x           x
      |FoObAr|   |FoObAr|    |FoObAr|    FoObAr      FoObAr      FoObAr
      |fOo|      |fOo|       |fOo|       fOo         fOo         fOo

      \x         \x          \x          x           x           x
      F\oO\bA\r  f\oo\ba\r   F\oo\ba\r   FoObAr      foobar      Foobar
      \fO\o      \fo\o       \fo\o       fOo         foo         foo

      Possible output under LIKE-WRITE-STRING:

      |x|        |x|         |x|         x           x           x
      |FoObAr|   |FoObAr|    |FoObAr|    FoObAr      FoObAr      FoObAr
      |fOo|      |fOo|       |fOo|       fOo         fOo         fOo

      \x         \x          \x          x           x           x
      F\oO\bA\r  f\oo\ba\r   F\oo\ba\r   FoObAr      FoObAr      FoObAr
      \fO\o      \fo\o       \fo\o       fOo         fOo         fOo

      Possible output under VERTICAL-BAR-RULE-NO-UPCASE:

      |x|        |x|         |x|         x           x           x
      |FoObAr|   |FoObAr|    |FoObAr|    FoObAr      foobar      Foobar
      |fOo|      |fOo|       |fOo|       fOo         foo         foo

      \x         \x          \x          x           x           x
      F\oO\bA\r  f\oo\ba\r   F\oo\ba\r   FoObAr      foobar      Foobar
      \fO\o      \fo\o       \fo\o       fOo         foo         foo

      Possible output under VERTICAL-BAR-RULE-PERMIT-UPCASE:

      |x|        |x|         |x|         X           x           X
      |FoObAr|   |FoObAr|    |FoObAr|    FOOBAR      foobar      Foobar
      |fOo|      |fOo|       |fOo|       FOO         foo         Foo

      \x         \x          \x          X           x           X
      F\oO\bA\r  f\oo\ba\r   F\oo\ba\r   FOOBAR      foobar      Foobar
      \fO\o      \fO\o       \fO\o       FOO         foo         Foo

    Rationale:

      It's silly for implementations to vary on this point.

    Current Practice:

      A strict reading of CLtL suggests that probably VERTICAL-BAR-RULE-NO-UPCASE
      is the most correct.

      Symbolics Genera doesn't do any of these. It was trying to do
      VERTICAL-BAR-NO-UPCASE, but it had a bug which was about to be fixed when
      this issue was raised.

    Cost to Implementors:

      Probably trivial.

    Cost to Users:

      Negligible in most cases. Probably very few users depend on this.
      Those who do depend on it probably do so because they think the
      behavior doesn't vary and probably don't get the portable behavior they
      expect.

    Cost of Non-Adoption:

      Gratuitous variation between implementations.

    Benefits:

      Cost of non-adoption is avoided.

    Aesthetics:

      Anything that makes the language tighter probably improves aesthetics.

      Only VERTICAL-BAR-RULE-PERMIT-UPCASE and LIKE-WRITE-STRING have really
      useful behaviors in the :ESCAPE NIL situation. Of these, perhaps only
      VERTICAL-BAR-RULE-PERMIT-UPCASE is really visually pleasant.

    Discussion:

      Pitman doesn't think the particular choice is very important. He just
      wants the issue to be resolved. His slight preference is for
      VERTICAL-BAR-RULE-PERMIT-UPCASE, then LIKE-WRITE-STRING, then either
      of LIKE-PRIN1 or VERTICAL-BAR-RULE-NO-UPCASE. He sees no reason to go
      with EXPLICITLY-VAGUE unless we deadlock.

      Michael Greenwald, who raised the issue at Symbolics, doesn't have
      a preference either but believes that CLtL (perhaps unintentionally)
      leans toward VERTICAL-BAR-RULE-NO-UPCASE.

    -----
    Additional Discussion from CL-Cleanup:

      David Gray responds:
        >   Possible output under VERTICAL-BAR-RULE-NO-UPCASE:
        >
        >   |x|        |x|         |x|         x           x           x
        >   |FoObAr|   |FoObAr|    |FoObAr|    FoObAr      foobar      Foobar
        >   |fOo|      |fOo|       |fOo|       fOo         foo         foo
        This is exactly what the Explorer does.

    There are several options for this issue, but if you're looking for one
    to focus on, VERTICAL-BAR-RULE-NO-UPCASE is probably the one we'll push
    if this issue comes up for discussion since it is believed most compatible
    with current practice.
     -kmp

Copyright 1996-2005, LispWorks Ltd. All rights reserved.