[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION (Version 1)



Trust me. You're gonna love this one! -kmp

-----
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
Status:	      For Internal Discussion

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.