[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PRINC-CHARACTER (Version 2)
- To: CL-Cleanup@SAIL.STANFORD.EDU
- Subject: PRINC-CHARACTER (Version 2)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 29 Apr 87 15:46 EDT
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
I removed the FORMAT-OP-C proposal from this since no one seemed to be
championing it. As far as I know, this was the only simplification anyone
had asked for. -kmp
References: PRINC (p383)
Edit History: 23-Feb-87, Version 1 by Pitman
29-Apr-87, Version 2 by Pitman (removed FORMAT-OP-C)
Status: For Internal Discussion
The manual is not adequately specific about the function of PRINC
when given a character as an argument.
For example, does (PRINC #\Space) print ``Space'' or `` ''?
The advice that "the general rule is that output from PRINC is
intended to look good to people" is the root of a lot of the problem.
The truth is that what looks good varies with context. viz,
* For (FORMAT NIL "Foo~ABar" #\Space)
Pretty result: "Foo Bar"
Ugly result: "FooSpaceBar"
In other words, " " looks better here.
* For (FORMAT T "Type ~C to continue" #\Space)
Pretty result: "Type Space to continue"
Ugly result: "Type to continue"
In other words, "Space" looks better here.
(PRINC char stream) should be defined to be equivalent to
(WRITE-CHAR char stream).
The behavior of (PRINC char) should be well-defined even if a
completely arbitrary decision had to be made.
In fact, though, we can get some advice by appealing to history.
The only data type which corresponds to characters in most old
lisps was symbols. For example, in Maclisp,
(PRINC char-symbol) == (TYO (GETCHARN char-symbol 1))
In Common Lisp, it would make sense in the absence of arguments
to the contrary to preserve an analagous relation, namely:
(PRINC char) == (WRITE-CHAR char)
Vaxlisp, Symbolics, Spice Lisp, and Lucid all print " " and not
"Space" for (PRINC #\Space).
Symbolics and Spice are known to use the WRITE-CHAR strategy.
Vaxlisp and Lucid might be using it, too, or they might be
using ~C in FORMAT; no one familiar with their internals has
In any case, some other implementations are believed to differ
(ie, to output "Space" when you PRINC a #\Space), but a specific
reference is not currently available. In any case, the wording
in CLtL is not clear enough to preclude such a differing
implementation from `legitimately' emerging.
Any implementations which did not already implement this proposal
decided upon would suffer an incompatible change.
User code that uses PRINC (and presumably ~A) on characters would
have a chance of being portable.
It's easy to search for occurrences of PRINC and ~A in code, but
it may not always be apparent when the argument is a character.
Automatic conversion is unlikely to succeed.
Making PRINC do something well-defined for as many primitive data
types as possible will probably be perceived as a simplification.
KMP thinks this is moderately important because it is embarrassing
to have commonly used functions like this vary so widely in behavior
between implementations. He doesn't think it is critical because
(if nothing else) it is only one of many problems with the vague
contract of PRINC.
There was an alternate proposal PRINC-CHARACTER:FORMAT-OP-C which
suggested making PRINC work like ~C in FORMAT, but no one seemed
to think that was useful and the proposal was removed for Version 2
to keep from muddying what's likely to be a very straightforward
vote in favor of PRINC-CHARACTER:WRITE-CHAR.