178 lines
13 KiB
HTML
178 lines
13 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 CONCATENATE-SEQUENCE 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/iss072_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss073.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss074_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/iss072_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss073.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss074_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue CONCATENATE-SEQUENCE Writeup</H2>
|
|
|
|
<PRE><B>Issue:</B> <A HREF="iss073.htm">CONCATENATE-SEQUENCE</A><P>
|
|
<B>Forum:</B> Editorial<P>
|
|
<B>References:</B> <A REL=DEFINITION HREF="../Body/f_concat.htm#concatenate"><B>CONCATENATE</B></A> (p249), <A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A> (p51),<P>
|
|
<A REL=DEFINITION HREF="../Body/f_mk_seq.htm#make-sequence"><B>MAKE-SEQUENCE</B></A> (p249), <A REL=DEFINITION HREF="../Body/f_map.htm#map"><B>MAP</B></A> (p249), <A REL=DEFINITION HREF="../Body/f_merge.htm#merge"><B>MERGE</B></A> (p260),<P>
|
|
Issue <A HREF="iss335.htm">SUBTYPEP-TOO-VAGUE</A><P>
|
|
<B>Category:</B> CLARIFICATION/CHANGE<P>
|
|
<B>Edit history:</B> 01-Mar-91, Version 1 by Pitman <P>
|
|
(only about (<A REL=DEFINITION HREF="../Body/f_concat.htm#concatenate"><B>CONCATENATE</B></A> '<A REL=DEFINITION HREF="../Body/t_seq.htm#sequence"><B>SEQUENCE</B></A> ...))<P>
|
|
15-Mar-91, Version 2 by Pitman <P>
|
|
(generalize per JonL, Moon, Barmar, MacLachlan)<P>
|
|
17-Mar-91, Version 3 by Pitman <P>
|
|
(clarify for MacLachlan; also, include <A REL=DEFINITION HREF="../Body/f_mk_seq.htm#make-sequence"><B>MAKE-SEQUENCE</B></A>)<P>
|
|
31-May-91, Version 4 by Pitman (amendments per X3J13)<P>
|
|
<B>Status:</B> X3J13 passed v3 with amendments on 10-1 vote, Mar 91.<P>
|
|
v4 reflects those amendments.<P>
|
|
<P>
|
|
<B>Problem Description:<P>
|
|
</B><P>
|
|
CLtL (p249) says that the RESULT-TYPE argument to <A REL=DEFINITION HREF="../Body/f_concat.htm#concatenate"><B>CONCATENATE</B></A><P>
|
|
``must be a subtype of <A REL=DEFINITION HREF="../Body/t_seq.htm#sequence"><B>SEQUENCE</B></A>, as for the function <A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A>''<P>
|
|
<P>
|
|
CLtL (p51) says:<P>
|
|
``Any sequence type may be converted to any other sequence<P>
|
|
type, provided the new sequence can contain all actual<P>
|
|
elements of the old sequence ... If the sequence is already<P>
|
|
the specified type, it may be returned without copying it; <P>
|
|
in this, (<A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A> sequence type) differs from <P>
|
|
(<A REL=DEFINITION HREF="../Body/f_concat.htm#concatenate"><B>CONCATENATE</B></A> type sequence), for the latter is required to<P>
|
|
copy the argument seqeunce. In particular, if one specifies<P>
|
|
<A REL=DEFINITION HREF="../Body/t_seq.htm#sequence"><B>SEQUENCE</B></A>, then the argument may simply be returned if it <P>
|
|
already is a sequence.<P>
|
|
<P>
|
|
The passage about <A REL=DEFINITION HREF="../Body/f_concat.htm#concatenate"><B>CONCATENATE</B></A> suggests that sequence subtypes <P>
|
|
valid to <A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A> are valid to <A REL=DEFINITION HREF="../Body/f_concat.htm#concatenate"><B>CONCATENATE</B></A>. But the type <A REL=DEFINITION HREF="../Body/t_seq.htm#sequence"><B>SEQUENCE</B></A><P>
|
|
is a subtype of <A REL=DEFINITION HREF="../Body/t_seq.htm#sequence"><B>SEQUENCE</B></A> that is clearly permissible to <A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A>.<P>
|
|
<P>
|
|
<A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A>, <A REL=DEFINITION HREF="../Body/f_mk_seq.htm#make-sequence"><B>MAKE-SEQUENCE</B></A>, <A REL=DEFINITION HREF="../Body/f_map.htm#map"><B>MAP</B></A>, and <A REL=DEFINITION HREF="../Body/f_merge.htm#merge"><B>MERGE</B></A> are also impacted similarly.<P>
|
|
<P>
|
|
<B>Terminology:<P>
|
|
</B><P>
|
|
Draft 8.81 of the specification defines the following term:<P>
|
|
<P>
|
|
recognizable subtype n. (of a <type>)<P>
|
|
a <subtype> of the <type> which can be reliably detected <P>
|
|
to be such by the <implementation>.<P>
|
|
<P>
|
|
The intent is that <A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A> will be described as a function which <P>
|
|
returns "T, T" when the first type argument is a "recognizable subtype"<P>
|
|
of the second.<P>
|
|
<P>
|
|
<B>Proposal (CONCATENATE-SEQUENCE:X3J13-MAR-91):<P>
|
|
</B><P>
|
|
1. Specify that <A REL=DEFINITION HREF="../Body/f_concat.htm#concatenate"><B>CONCATENATE</B></A>, <A REL=DEFINITION HREF="../Body/f_mk_seq.htm#make-sequence"><B>MAKE-SEQUENCE</B></A>, <A REL=DEFINITION HREF="../Body/f_map.htm#map"><B>MAP</B></A>, and <A REL=DEFINITION HREF="../Body/f_merge.htm#merge"><B>MERGE</B></A> are<P>
|
|
defined only when the target type argument is either a <P>
|
|
recognizable subtype of <A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>LIST</B></A> or a recognizable subtype of<P>
|
|
<A REL=DEFINITION HREF="../Body/a_vector.htm#vector"><B>VECTOR</B></A>. [MAP is also permitted to special case <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> as a<P>
|
|
target type in a manner consisting with existing practice.]<P>
|
|
Otherwise, an error is signaled.<P>
|
|
<P>
|
|
2. Specify that if <A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A> receives a target type argument which is <P>
|
|
a recognizable subtype of <A REL=DEFINITION HREF="../Body/t_seq.htm#sequence"><B>SEQUENCE</B></A>, but which is neither a <P>
|
|
recognizable subtype of <A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>LIST</B></A> nor a recognizable subtype of<P>
|
|
<A REL=DEFINITION HREF="../Body/a_vector.htm#vector"><B>VECTOR</B></A>, then the argument to be coerced must already be <P>
|
|
of that type (in which case, <A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A> behaves like <A REL=DEFINITION HREF="../Body/f_identi.htm#identity"><B>IDENTITY</B></A> for that<P>
|
|
argument). Otherwise, an error is signaled.<P>
|
|
<P>
|
|
3. a. Specify that if <A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A>, <A REL=DEFINITION HREF="../Body/f_concat.htm#concatenate"><B>CONCATENATE</B></A>, <A REL=DEFINITION HREF="../Body/f_mk_seq.htm#make-sequence"><B>MAKE-SEQUENCE</B></A>, <A REL=DEFINITION HREF="../Body/f_map.htm#map"><B>MAP</B></A>,<P>
|
|
or <A REL=DEFINITION HREF="../Body/f_merge.htm#merge"><B>MERGE</B></A> receives a target type argument which is any subtype<P>
|
|
of <A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>LIST</B></A>, then the result is of type <A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>LIST</B></A>.<P>
|
|
<P>
|
|
b. Specify that if <A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A> receives a target type argument that<P>
|
|
is a subtype of array, and the object is already of that type,<P>
|
|
<A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A> returns that object as its result.<P>
|
|
<P>
|
|
c. For <A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A> in situations not covered by 3b, <P>
|
|
<A REL=DEFINITION HREF="../Body/f_concat.htm#concatenate"><B>CONCATENATE</B></A>, <A REL=DEFINITION HREF="../Body/f_mk_seq.htm#make-sequence"><B>MAKE-SEQUENCE</B></A>, <A REL=DEFINITION HREF="../Body/f_map.htm#map"><B>MAP</B></A> and <A REL=DEFINITION HREF="../Body/f_merge.htm#merge"><B>MERGE</B></A> <P>
|
|
when the target type argument is a subtype of ARRAY:<P>
|
|
<P>
|
|
* If the implementation can determine the element type<P>
|
|
specified for the target type, the element type of the<P>
|
|
resulting array is the upgraded array element type of <P>
|
|
the specified element type.<P>
|
|
<P>
|
|
* Else if the implementation can determine that the element<P>
|
|
type is unspecified, (or ``*'') the element type of the<P>
|
|
resulting array defaults as for <A REL=DEFINITION HREF="../Body/f_mk_ar.htm#make-array"><B>MAKE-ARRAY</B></A> (to T).<P>
|
|
<P>
|
|
* Else an error is signaled.<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
This gives users a sense of what they can expect at minimum,<P>
|
|
and also gives implementors a sense for how they can go about <P>
|
|
making extensions without violating user expectations.<P>
|
|
<P>
|
|
Note that although that specific terminology is not used, the<P>
|
|
specific constraints on recognizable subtypes are effectively <P>
|
|
spelled out in issue <A HREF="iss335.htm">SUBTYPEP-TOO-VAGUE</A>.<P>
|
|
<P>
|
|
<B>Test Case:<P>
|
|
</B><P>
|
|
#1: (<A REL=DEFINITION HREF="../Body/f_concat.htm#concatenate"><B>CONCATENATE</B></A> '<A REL=DEFINITION HREF="../Body/t_seq.htm#sequence"><B>SEQUENCE</B></A> '(A B C) "DEF")<P>
|
|
<P>
|
|
#2: (<A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A> '#1=#(1 0 1) '(<A REL=DEFINITION HREF="../Body/a_or.htm#or"><B>OR</B></A> <A REL=DEFINITION HREF="../Body/a_null.htm#null"><B>NULL</B></A> (<A REL=DEFINITION HREF="../Body/a_eql.htm#eql"><B>EQL</B></A> (1 0 1))))<P>
|
|
<P>
|
|
#3: (<A REL=DEFINITION HREF="../Body/s_flet_.htm#flet"><B>FLET</B></A> ((SAME-TYPE-P (X Y)<P>
|
|
(<A REL=DEFINITION HREF="../Body/a_values.htm#values"><B>VALUES</B></A> (<A REL=DEFINITION HREF="../Body/a_and.htm#and"><B>AND</B></A> (<A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A> X Y) (<A REL=DEFINITION HREF="../Body/f_subtpp.htm#subtypep"><B>SUBTYPEP</B></A> Y X)))))<P>
|
|
(SAME-TYPE-P <P>
|
|
(<A REL=DEFINITION HREF="../Body/f_ar_ele.htm#array-element-type"><B>ARRAY-ELEMENT-TYPE</B></A> (<A REL=DEFINITION HREF="../Body/f_mk_seq.htm#make-sequence"><B>MAKE-SEQUENCE</B></A> '(<A REL=DEFINITION HREF="../Body/t_array.htm#array"><B>ARRAY</B></A> (<A REL=DEFINITION HREF="../Body/t_unsgn_.htm#unsigned-byte"><B>UNSIGNED-BYTE</B></A> 5)) 3))<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_upgr_1.htm#upgraded-array-element-type"><B>UPGRADED-ARRAY-ELEMENT-TYPE</B></A> '(<A REL=DEFINITION HREF="../Body/t_unsgn_.htm#unsigned-byte"><B>UNSIGNED-BYTE</B></A> 5))))<P>
|
|
=> T ;or signals an error, if (<A REL=DEFINITION HREF="../Body/t_unsgn_.htm#unsigned-byte"><B>UNSIGNED-BYTE</B></A> 5) is not upgradable.<P>
|
|
<P>
|
|
<B>Current Practice:<P>
|
|
</B><P>
|
|
Symbolics Genera seems to approximately implement this proposal, <P>
|
|
although it isn't quite right on the <A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>LIST</B></A> side (e.g., it fails on test<P>
|
|
case #2).<P>
|
|
<P>
|
|
<B>Cost to Implementors:<P>
|
|
</B><P>
|
|
Small.<P>
|
|
<P>
|
|
<B>Cost to Users:<P>
|
|
</B><P>
|
|
None. This was already not portable.<P>
|
|
<P>
|
|
<B>Cost of Non-Adoption:<P>
|
|
</B><P>
|
|
The language is left ambiguous.<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
A tighter specification--better portability.<P>
|
|
<P>
|
|
<B>Aesthetics:<P>
|
|
</B><P>
|
|
Negligible.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
Pitman supports this.<P>
|
|
<P>
|
|
An earlier version of this proposal worried specifically about the case<P>
|
|
of function <A REL=DEFINITION HREF="../Body/f_concat.htm#concatenate"><B>CONCATENATE</B></A> and specifically about the argument named <A REL=DEFINITION HREF="../Body/t_seq.htm#sequence"><B>SEQUENCE</B></A><P>
|
|
but it was shown that the problem was bigger along both axes, so v2 starts<P>
|
|
over trying to do things a different way.<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>
|