Contents|Symbol Index|Up: Issues|Prev: PRINC-CHARACTER|Next: PRINT-CIRCLE-SHARED

Cleanup Issue `PRINT-CASE-PRINT-ESCAPE-INTERACTION`

Status: proposal VERTICAL-BAR-RULE-NO-UPCASE passed, Jun 89 X3J13
Forum: Cleanup
Category: CLARIFICATION
References: *PRINT-ESCAPE* (pp370-371), *PRINT-CASE* (pp372), WRITE

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 (LIKE-PRIN1)

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

Proposal (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 (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 (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 (EXPLICITLY-VAGUE)

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

Test Cases

(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

Edit History

26-Jan-89, Version 1 by Pitman