169 lines
14 KiB
HTML
169 lines
14 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 SUBTYPEP-TOO-VAGUE 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/iss334_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss335.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss336_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/iss334_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss335.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss336_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue SUBTYPEP-TOO-VAGUE Writeup</H2>
|
|
|
|
<PRE><B>Status:</B> Passed, as amended, Jun89 X3J13<P>
|
|
<B>Issue:</B> <A HREF="iss335.htm">SUBTYPEP-TOO-VAGUE</A><P>
|
|
<B>References:</B> CLtL p. 72-73<P>
|
|
<B>Category:</B> CLARIFICATION<P>
|
|
<B>Edit History:</B> Version 1, 11 Jul 1988 (Sandra Loosemore)<P>
|
|
Version 2, 19 Jul 1988 (Sandra Loosemore)<P>
|
|
Version 3, 6-Oct-88 (Masinter)<P>
|
|
Version 4, 7-Oct-88 (Masinter, per Moon's comments)<P>
|
|
Version 5, 15-Mar-89 Steele<P>
|
|
Version 6, 2-Jul-89 Masinter (as per Jun89X3J13)<P>
|
|
<B>Problem Description:<P>
|
|
</B><P>
|
|
[From version 4]<P>
|
|
<P>
|
|
The description of <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A> allows it to return a second value of <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A><P>
|
|
when the relationship between the two types cannot be determined. In<P>
|
|
some cases this is a reasonable thing to do because it is impossible<P>
|
|
to tell (if the <A REL=DEFINITION HREF="../Body/t_satisf.htm#satisfies"><B>SATISFIES</B></A> type specifier is involved), and in other<P>
|
|
cases the relationships between types are not well-defined (for<P>
|
|
example, the <A REL=DEFINITION HREF="../Body/a_values.htm#values"><B>VALUES</B></A> type specifier or the list form of the <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A><P>
|
|
type specifier). <P>
|
|
<P>
|
|
Some implementations, however, have apparently interpreted this to<P>
|
|
mean that it is permissible for <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A> to "give up" and return a<P>
|
|
second value of <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> in some cases where it actually would be possible<P>
|
|
to determine the relationship. This makes it difficult to depend on<P>
|
|
subtype relationships in portable code.<P>
|
|
<P>
|
|
[Addition for version 5]<P>
|
|
<P>
|
|
There are two problems with version 4. First is that of the first three<P>
|
|
bulleted points in the version 4 proposal:<P>
|
|
<P>
|
|
* Clarify that <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A> will return a second value of <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A><P>
|
|
only when either of the type specifiers involves the <A REL=DEFINITION HREF="../Body/t_satisf.htm#satisfies"><B>SATISFIES</B></A>, <A REL=DEFINITION HREF="../Body/a_not.htm#not"><B>NOT</B></A>, <P>
|
|
<A REL=DEFINITION HREF="../Body/a_and.htm#and"><B>AND</B></A>, <A REL=DEFINITION HREF="../Body/a_or.htm#or"><B>OR</B></A>, <A REL=DEFINITION HREF="../Body/a_member.htm#member"><B>MEMBER</B></A>. <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A> will not return a second<P>
|
|
value of <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> when both arguments involve only the words in Table 4-1, or<P>
|
|
names of DEFSTRUCT- or DEFCLASS-defined types, or user-defined deftypes<P>
|
|
that expand into only those words and/or names.<P>
|
|
<P>
|
|
* <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A> should signal an error when handed (for either argument)<P>
|
|
a type specifier that involves <A REL=DEFINITION HREF="../Body/a_values.htm#values"><B>VALUES</B></A> or the list form of the <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A><P>
|
|
type.<P>
|
|
<P>
|
|
* <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A> must always return values T T in the case where the two<P>
|
|
type specifiers (or their expansions) are <A REL=DEFINITION HREF="../Body/f_equal.htm#equal"><B>EQUAL</B></A>.<P>
|
|
<P>
|
|
any two have significant overlap, and indeed all three can overlap;<P>
|
|
version 4 contained no indication of how this conflict should be resolved.<P>
|
|
<P>
|
|
Second is that version 4 calls for <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A> to signal an error (at least at<P>
|
|
high safety)even when the arguments are valid type specifiers, but this can<P>
|
|
make it harder to use <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A>. These are cases that returning <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A><P>
|
|
was supposed to cover.<P>
|
|
<P>
|
|
This version replaces the three bulleted points above with a single point<P>
|
|
and some observations about its consequences. This version eliminates<P>
|
|
the requirement to signal an error.<P>
|
|
<P>
|
|
<P>
|
|
Proposal: <A HREF="iss335.htm">SUBTYPEP-TOO-VAGUE:CLARIFY-MORE</A><P>
|
|
<P>
|
|
A type specifier "involves" a word like <A REL=DEFINITION HREF="../Body/t_satisf.htm#satisfies"><B>SATISFIES</B></A>, <A REL=DEFINITION HREF="../Body/a_member.htm#member"><B>MEMBER</B></A>, <A REL=DEFINITION HREF="../Body/a_not.htm#not"><B>NOT</B></A>, etc.<P>
|
|
if it either contains it directly as a type specifier, <P>
|
|
or as the result of expansion of a <A REL=DEFINITION HREF="../Body/m_deftp.htm#deftype"><B>DEFTYPE</B></A> defined type specifier. <P>
|
|
(While <A REL=DEFINITION HREF="../Body/s_the.htm#the"><B>the</B></A> <A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>type</B></A> specifiers listed in CLtL Table 4-1 <A REL=DEFINITION HREF="../Body/a_and.htm#and"><B>and</B></A> names of<P>
|
|
<A REL=DEFINITION HREF="../Body/m_defstr.htm#defstruct"><B>DEFSTRUCT</B></A> <A REL=DEFINITION HREF="../Body/a_or.htm#or"><B>or</B></A> DEFCLASS-defined types may, in <A REL=DEFINITION HREF="../Body/f_everyc.htm#some"><B>some</B></A> cases, be implemented<P>
|
|
in terms of <A REL=DEFINITION HREF="../Body/m_deftp.htm#deftype"><B>DEFTYPE</B></A>, they are to be regarded for this purpose as <A REL=DEFINITION HREF="../Body/a_not.htm#not"><B>not</B></A><P>
|
|
being "user-defined". Therefore, <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A> must regard elements as<P>
|
|
primitive with respect to <A REL=DEFINITION HREF="../Body/s_the.htm#the"><B>the</B></A> question of returning <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A>.)<P>
|
|
<P>
|
|
* Clarify that <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A> is permitted to return <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> only when<P>
|
|
at least one argument involves <A REL=DEFINITION HREF="../Body/t_satisf.htm#satisfies"><B>SATISFIES</B></A>, <A REL=DEFINITION HREF="../Body/a_and.htm#and"><B>AND</B></A>, <A REL=DEFINITION HREF="../Body/a_or.htm#or"><B>OR</B></A>, <A REL=DEFINITION HREF="../Body/a_not.htm#not"><B>NOT</B></A>, <A REL=DEFINITION HREF="../Body/a_member.htm#member"><B>MEMBER</B></A>,<P>
|
|
<A REL=DEFINITION HREF="../Body/a_values.htm#values"><B>VALUES</B></A>, or the list form of <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A>.<P>
|
|
<P>
|
|
Note that one consequence of this is that if neither argument<P>
|
|
involves any of these type specifiers, then <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A> is obliged<P>
|
|
to determine the relationship accurately. In particular, <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A><P>
|
|
must return T T if the arguments are <A REL=DEFINITION HREF="../Body/f_equal.htm#equal"><B>EQUAL</B></A> and do not involve<P>
|
|
any of the above-stated type specifiers.<P>
|
|
<P>
|
|
* Clarify that the relationships between types reflected by <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A><P>
|
|
are those specific to the particular implementation. For example, if<P>
|
|
an implementation supports only a single type of floating-point numbers,<P>
|
|
in that implementation (<A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A> '<A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>FLOAT</B></A> '<A REL=DEFINITION HREF="../Body/t_short_.htm#long-float"><B>LONG-FLOAT</B></A>) would return T T<P>
|
|
(since the two types would be identical).<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
Specifying the behavior of <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A> makes it more useful. Otherwise,<P>
|
|
programs cannot rely on any more than <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> as return values.<P>
|
|
<P>
|
|
It is generally conceded that it is impossible to determine the<P>
|
|
relationships between types defined with the <A REL=DEFINITION HREF="../Body/t_satisf.htm#satisfies"><B>SATISFIES</B></A> specifier.<P>
|
|
<A REL=DEFINITION HREF="../Body/a_member.htm#member"><B>MEMBER</B></A>, <A REL=DEFINITION HREF="../Body/a_and.htm#and"><B>AND</B></A>, <A REL=DEFINITION HREF="../Body/a_or.htm#or"><B>OR</B></A>, and <A REL=DEFINITION HREF="../Body/a_not.htm#not"><B>NOT</B></A> are messy to deal with. <P>
|
|
<P>
|
|
<B>Current Practice:<P>
|
|
</B><P>
|
|
The implementation of <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A> in (the original) HPCL does not try to<P>
|
|
expand type specifiers defined with <A REL=DEFINITION HREF="../Body/m_deftp.htm#deftype"><B>DEFTYPE</B></A> and does not recognize<P>
|
|
<A REL=DEFINITION HREF="../Body/f_equal.htm#equal"><B>EQUAL</B></A> type specifiers as being equivalent. Most other implementations<P>
|
|
appear to be substantially in conformance with the proposal.<P>
|
|
<P>
|
|
<B>Cost to implementors:<P>
|
|
</B><P>
|
|
Some implementations will have to rewrite and/or extend parts of <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A>.<P>
|
|
<P>
|
|
<B>Cost to users:<P>
|
|
</B><P>
|
|
Its hard to imagine a portable program that depends heavily<P>
|
|
on <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A>. This proposal does not <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> any implementation<P>
|
|
to "handle" fewer cases of <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A>.<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
An area of confusion in the language is cleared up. Usages of <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A><P>
|
|
will be more portable.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
The handling of <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>FLOAT</B></A> and <A REL=DEFINITION HREF="../Body/t_short_.htm#single-float"><B>SINGLE-FLOAT</B></A> appeared to be the <P>
|
|
consensus from a discussion on the common-lisp mailing list some<P>
|
|
time ago.<P>
|
|
<P>
|
|
It would not be too onerous to <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> implementations to handle<P>
|
|
the cases where one but not the other type specifier involves<P>
|
|
<A REL=DEFINITION HREF="../Body/a_or.htm#or"><B>OR</B></A>, <A REL=DEFINITION HREF="../Body/a_and.htm#and"><B>AND</B></A>, <A REL=DEFINITION HREF="../Body/a_not.htm#not"><B>NOT</B></A> or <A REL=DEFINITION HREF="../Body/a_member.htm#member"><B>MEMBER</B></A>, but the specification becomes <P>
|
|
cumbersome.<P>
|
|
<P>
|
|
A related issue is clarifying what kinds of type specifiers must be<P>
|
|
recognized by functions such as <A REL=DEFINITION HREF="../Body/f_mk_seq.htm#make-sequence"><B>MAKE-SEQUENCE</B></A> and <A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A>. For example,<P>
|
|
HPCL complains that (<A REL=DEFINITION HREF="../Body/t_smp_ar.htm#simple-array"><B>SIMPLE-ARRAY</B></A> (<A REL=DEFINITION HREF="../Body/t_unsgn_.htm#unsigned-byte"><B>UNSIGNED-BYTE</B></A> *) (*)) is not a valid<P>
|
|
sequence type when passed to <A REL=DEFINITION HREF="../Body/f_mk_seq.htm#make-sequence"><B>MAKE-SEQUENCE</B></A>, although <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A> does<P>
|
|
recognize it to be a subtype of <A REL=DEFINITION HREF="../Body/t_seq.htm#sequence"><B>SEQUENCE</B></A>. Should this proposal be<P>
|
|
extended to deal with these issues, or is another proposal in order?<P>
|
|
<P>
|
|
The rules for comparing the various type specifiers (such as <A REL=DEFINITION HREF="../Body/t_array.htm#array"><B>ARRAY</B></A>)<P>
|
|
need to be spelled out in detail.<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>
|