130 lines
7.6 KiB
HTML
130 lines
7.6 KiB
HTML
<!-- Common Lisp HyperSpec (TM), version 7.0 generated by Kent M. Pitman on Mon, 11-Apr-2005 2:31am EDT -->
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>CLHS: Issue FORMAT-OP-C Writeup</TITLE>
|
|
<LINK HREF="../Data/clhs.css" REL="stylesheet" TYPE="text/css" />
|
|
<META HTTP-EQUIV="Author" CONTENT="Kent M. Pitman">
|
|
<META HTTP-EQUIV="Organization" CONTENT="LispWorks Ltd.">
|
|
<LINK REL=TOP HREF="../Front/index.htm">
|
|
<LINK REL=COPYRIGHT HREF="../Front/Help.htm#Legal">
|
|
<LINK REL=DISCLAIMER HREF="../Front/Help.htm#Disclaimer">
|
|
<LINK REL=PREV HREF="../Issues/iss167_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss168.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss169_w.htm">
|
|
</HEAD>
|
|
<BODY>
|
|
<H1><A REV=MADE HREF="http://www.lispworks.com/"><IMG WIDTH=80 HEIGHT=65 ALT="[LISPWORKS]" SRC="../Graphics/LWSmall.gif" ALIGN=Bottom></A><A REL=TOP HREF="../Front/index.htm"><IMG WIDTH=237 HEIGHT=65 ALT="[Common Lisp HyperSpec (TM)]" SRC="../Graphics/CLHS_Sm.gif" ALIGN=Bottom></A> <A REL=PREV HREF="../Issues/iss167_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss168.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss169_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue FORMAT-OP-C Writeup</H2>
|
|
|
|
<PRE><B>Issue:</B> <A HREF="iss168.htm">FORMAT-OP-C</A><P>
|
|
<B>References:</B> <A REL=DEFINITION HREF="../Body/f_wr_cha.htm#write-char"><B>WRITE-CHAR</B></A> (p384), ~C (p389)<P>
|
|
<B>Category:</B> CHANGE/CLARIFICATION<P>
|
|
<B>Edit History:</B> 23-Feb-87, Version 1 by Pitman<P>
|
|
29-Apr-87, Versions 2,3 by Pitman<P>
|
|
5-Jun-87, Version 4 by Masinter (copy-editing)<P>
|
|
11-Jun-87, Version 5 release to X3J13<P>
|
|
(remove confusing paragraph)<P>
|
|
<P>
|
|
<B>Problem Description:<P>
|
|
</B><P>
|
|
CLtL is not adequately specific about the function of the format<P>
|
|
operation ~C. The description on p389 says that "~C prints the character<P>
|
|
in an implementation-dependent abbreviated format. This format should be<P>
|
|
culturally compatible with the host environment." This description is<P>
|
|
not very useful in practice.<P>
|
|
<P>
|
|
Presumably the authors intended the `cultural compatibility' part to<P>
|
|
gloss issues like how the SAIL character set printed, but unfortunately<P>
|
|
another completely reasonable (albeit unplanned) interpretation arose:<P>
|
|
some implementations have (<A REL=DEFINITION HREF="../Body/f_format.htm#format"><B>FORMAT</B></A> <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> "~C" #\Space) => "Space" rather<P>
|
|
than " ".<P>
|
|
<P>
|
|
Since the behavior of ~A is also vague on characters (a separate<P>
|
|
proposal will address this), the only way to safely output a literal<P>
|
|
character is to WRITE-CHAR; currently, <A REL=DEFINITION HREF="../Body/f_format.htm#format"><B>FORMAT</B></A> does not suffice.<P>
|
|
<P>
|
|
<B>Proposal (FORMAT-OP-C:WRITE-CHAR):<P>
|
|
</B><P>
|
|
Change the behavior of ~C to say that, when given a character with zero<P>
|
|
bits, it will perform the same action as <A REL=DEFINITION HREF="../Body/f_wr_cha.htm#write-char"><B>WRITE-CHAR</B></A>. (This proposal<P>
|
|
leaves the behavior of ~C with non-zero bits incompletely specified.)<P>
|
|
For example, the description of the ~C format directive on p389 of CLTL<P>
|
|
might read:<P>
|
|
<P>
|
|
~C prints the character using <A REL=DEFINITION HREF="../Body/f_wr_cha.htm#write-char"><B>WRITE-CHAR</B></A> if it has zero bits.<P>
|
|
Characters with bits are not necessarily printed as <A REL=DEFINITION HREF="../Body/f_wr_cha.htm#write-char"><B>WRITE-CHAR</B></A><P>
|
|
would do, but are displayed in an implementation-dependent<P>
|
|
abbreviated format that is culturally compatible with the host<P>
|
|
environment.<P>
|
|
<P>
|
|
<B>Test Case:<P>
|
|
</B><P>
|
|
(<A REL=DEFINITION HREF="../Body/f_equal.htm#equal"><B>EQUAL</B></A> (<A REL=DEFINITION HREF="../Body/f_format.htm#format"><B>FORMAT</B></A> <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> "~C" #\Space) " ")<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
This was probably the intent of the Common Lisp designers. <P>
|
|
<P>
|
|
It makes things clear enough that programmers can know what to expect in<P>
|
|
the normal case (<A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> characters with zero bits).<P>
|
|
<P>
|
|
Users can use (<A REL=DEFINITION HREF="../Body/f_format.htm#format"><B>FORMAT</B></A> <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> "~:C" #\Space) to get "Space" if they want it.<P>
|
|
It seems as if the implementations which return "Space" treat ~C and ~:C<P>
|
|
equivalently or very similarly.<P>
|
|
<P>
|
|
<B>Current Practice:<P>
|
|
</B><P>
|
|
Implementations are divided. Some implementations have<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_format.htm#format"><B>FORMAT</B></A> <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> "~C" #\Space) => "Space".<P>
|
|
Others have the same form return " ".<P>
|
|
<P>
|
|
<B>Adoption Cost:<P>
|
|
</B><P>
|
|
Those implementations which did not already implement ~C as <A REL=DEFINITION HREF="../Body/f_wr_cha.htm#write-char"><B>WRITE-CHAR</B></A><P>
|
|
would <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> an incompatible change.<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
User code that uses ~C would have a chance of being portable. As things<P>
|
|
stand, users who use ~C can't reliably port their code.<P>
|
|
<P>
|
|
~C and ~:C would perform usefully distinct operations.<P>
|
|
<P>
|
|
<B>Conversion Cost:<P>
|
|
</B><P>
|
|
Standard ``Query Replace'' technology for finding occurrences of "~C"<P>
|
|
and changing them to "~:C" semi-automatically should suffice.<P>
|
|
<P>
|
|
<B>Aesthetics:<P>
|
|
</B><P>
|
|
Making ~C do something well-defined will probably be perceived as a<P>
|
|
simplification.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
The cleanup committee generally supports this clarification.<P>
|
|
<P>
|
|
The original version of this proposal (which tried to make <A REL=DEFINITION HREF="../Body/f_wr_cha.htm#write-char"><B>WRITE-CHAR</B></A><P>
|
|
and ~C identical in all cases) prompted the following comment:<P>
|
|
<P>
|
|
"I believe the error in CLtL is that it was not stated explicitly that<P>
|
|
the `implementation-dependent abbreviated format' applies only to<P>
|
|
characters with non-zero char-bits. Thus instead of removing the<P>
|
|
mumbling about cultural compatibility, I suggest simply adding a<P>
|
|
sentence saying that ~C is the same as <A REL=DEFINITION HREF="../Body/f_wr_cha.htm#write-char"><B>WRITE-CHAR</B></A> for characters with<P>
|
|
zero char-bits. I don't think we want to <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> ~C and <A REL=DEFINITION HREF="../Body/f_wr_cha.htm#write-char"><B>write-char</B></A> to<P>
|
|
do the same thing for characters with bits."<P>
|
|
<P>
|
|
</PRE>
|
|
<HR>
|
|
|
|
<A REL=NAVIGATOR HREF="../Front/StartPts.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Starting Points]" SRC="../Graphics/StartPts.gif" ALIGN=Bottom></A><A REL=TOC HREF="../Front/Contents.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Contents]" SRC="../Graphics/Contents.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Master.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Index]" SRC="../Graphics/Index.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Symbol.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Symbols]" SRC="../Graphics/Symbols.gif" ALIGN=Bottom></A><A REL=GLOSSARY HREF="../Body/26_a.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Glossary]" SRC="../Graphics/Glossary.gif" ALIGN=Bottom></A><A HREF="../Front/X3J13Iss.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Issues]" SRC="../Graphics/Issues.gif" ALIGN=Bottom></A><BR>
|
|
|
|
<A REL=COPYRIGHT HREF="../Front/Help.htm#Legal"><I>Copyright 1996-2005, LispWorks Ltd. All rights reserved.</I></A><P>
|
|
</BODY>
|
|
</HTML>
|