CLHS: Issue PRINT-CASE-PRINT-ESCAPE-INTERACTION Writeup

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

|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

|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

|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

|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

> |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