[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION (Version 1)
- To: CL-Cleanup@SAIL.Stanford.EDU
- Subject: Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 26 Jan 89 15:13 EST
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
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.