147 lines
9.4 KiB
HTML
147 lines
9.4 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 SEQUENCE-TYPE-LENGTH 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/iss301_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss302.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss303_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/iss301_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss302.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss303_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue SEQUENCE-TYPE-LENGTH Writeup</H2>
|
|
|
|
<PRE><B>Issue:</B> <A HREF="iss302.htm">SEQUENCE-TYPE-LENGTH</A><P>
|
|
<P>
|
|
<B>References:</B> CLtL p.51, p.249, p.260, p.252, p.354<P>
|
|
<A REL=DEFINITION HREF="../Body/f_concat.htm#concatenate"><B>CONCATENATE</B></A>, <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>, <A REL=DEFINITION HREF="../Body/f_merge.htm#merge"><B>MERGE</B></A><P>
|
|
<P>
|
|
<B>Category:</B> CLARIFICATION<P>
|
|
<P>
|
|
<B>Edit history:</B> 16-Jun-89, version 1, by Moon<P>
|
|
<P>
|
|
<B>Problem description:<P>
|
|
</B><P>
|
|
In several functions that take a type specifier as an argument and create<P>
|
|
a sequence of the specified type, it isn't clear what happens if the type<P>
|
|
specifier has an explicit length that doesn't match the length implied by<P>
|
|
the other arguments.<P>
|
|
<P>
|
|
<B>Proposal (SEQUENCE-TYPE-LENGTH:MUST-MATCH):<P>
|
|
</B><P>
|
|
<A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A> should signal an error if the new sequence type specifies the<P>
|
|
number of elements and the old sequence has a different length.<P>
|
|
<P>
|
|
<A REL=DEFINITION HREF="../Body/f_mk_seq.htm#make-sequence"><B>MAKE-SEQUENCE</B></A> should signal an error if the sequence type specifies the<P>
|
|
number of elements and the size argument is different.<P>
|
|
<P>
|
|
<A REL=DEFINITION HREF="../Body/f_concat.htm#concatenate"><B>CONCATENATE</B></A> should signal an error if the sequence type specifies the<P>
|
|
number of elements and the sum of the argument lengths is different.<P>
|
|
<P>
|
|
<A REL=DEFINITION HREF="../Body/f_map.htm#map"><B>MAP</B></A> should signal an error if the sequence type specifies the number of<P>
|
|
elements and the minimum of the argument lengths is different.<P>
|
|
<P>
|
|
<A REL=DEFINITION HREF="../Body/f_merge.htm#merge"><B>MERGE</B></A> should signal an error if the sequence type specifies the number of<P>
|
|
elements and the sum of the lengths of the two sequence arguments is<P>
|
|
different.<P>
|
|
<P>
|
|
<B>Examples:<P>
|
|
</B><P>
|
|
;; All of the following forms should signal an error<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>coerce</B></A> '(a b c) '(<A REL=DEFINITION HREF="../Body/a_vector.htm#vector"><B>vector</B></A> * 4))<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>coerce</B></A> #(a b c) '(<A REL=DEFINITION HREF="../Body/a_vector.htm#vector"><B>vector</B></A> * 4))<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>coerce</B></A> '(a b c) '(<A REL=DEFINITION HREF="../Body/a_vector.htm#vector"><B>vector</B></A> * 2))<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>coerce</B></A> #(a b c) '(<A REL=DEFINITION HREF="../Body/a_vector.htm#vector"><B>vector</B></A> * 2))<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>coerce</B></A> "foo" '(<A REL=DEFINITION HREF="../Body/a_string.htm#string"><B>string</B></A> 2))<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>coerce</B></A> #(#\a #\b #\c) '(<A REL=DEFINITION HREF="../Body/a_string.htm#string"><B>string</B></A> 2))<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>coerce</B></A> '(0 1) '(<A REL=DEFINITION HREF="../Body/t_smp_bt.htm#simple-bit-vector"><B>simple-bit-vector</B></A> 3))<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_mk_seq.htm#make-sequence"><B>make-sequence</B></A> '(<A REL=DEFINITION HREF="../Body/a_vector.htm#vector"><B>vector</B></A> * 2) 3)<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_mk_seq.htm#make-sequence"><B>make-sequence</B></A> '(<A REL=DEFINITION HREF="../Body/a_vector.htm#vector"><B>vector</B></A> * 4) 3)<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_concat.htm#concatenate"><B>concatenate</B></A> '(<A REL=DEFINITION HREF="../Body/a_vector.htm#vector"><B>vector</B></A> * 2) "a" "bc")<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_map.htm#map"><B>map</B></A> '(<A REL=DEFINITION HREF="../Body/a_vector.htm#vector"><B>vector</B></A> * 4) #'<A REL=DEFINITION HREF="../Body/a_cons.htm#cons"><B>cons</B></A> "abc" "de")<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_merge.htm#merge"><B>merge</B></A> '(<A REL=DEFINITION HREF="../Body/a_vector.htm#vector"><B>vector</B></A> * 4) '(1 5) '(2 4 6) #'<)<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
If CLtL hadn't overlooked this situation, it's likely that it would have<P>
|
|
said it "is an error". The best translation of that to ANSI CL error<P>
|
|
terminology seemed to be "should signal". There doesn't seem to be any<P>
|
|
reason to <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> signalling this error even in unsafe code. There<P>
|
|
doesn't seem to be any reason to define this situation to do something<P>
|
|
other than signalling an error, such as ignoring the length in the<P>
|
|
type specifier or forcing the sequence to have the correct length by<P>
|
|
truncating or extending it with elements of implementation-dependent<P>
|
|
value.<P>
|
|
<P>
|
|
<B>Current practice:<P>
|
|
</B><P>
|
|
Symbolics Genera 7.2 and 7.4 usually ignore the length in the type<P>
|
|
specifier in the above situations, but sometimes signal an error.<P>
|
|
The type of error signalled is sometimes somewhat random.<P>
|
|
Other implementations were not surveyed.<P>
|
|
<P>
|
|
<B>Cost to Implementors:<P>
|
|
</B><P>
|
|
This does not seem like difficult checking to add. I have not examined<P>
|
|
the code in any implementation to try to evaluate what it would cost.<P>
|
|
<P>
|
|
<B>Cost to Users:<P>
|
|
</B><P>
|
|
None.<P>
|
|
<P>
|
|
<B>Cost of non-adoption:<P>
|
|
</B><P>
|
|
Aesthetic.<P>
|
|
<P>
|
|
<B>Performance impact:<P>
|
|
</B><P>
|
|
Probably small, just have to keep track of the length when dealing<P>
|
|
with sequence type specifiers in safe code. I have not attempted to<P>
|
|
evaluate the exact impact.<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
Less ambiguity in the language specification. Less deviation among<P>
|
|
implementations, hence fewer porting problems.<P>
|
|
<P>
|
|
<B>Esthetics:<P>
|
|
</B><P>
|
|
Since the length field is present in sequence type specifiers, it<P>
|
|
seems unesthetic to ignore it, and even more unesthetic not to say<P>
|
|
what is done with it.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
Moon doesn't know what error condition is appropriate. <A REL=DEFINITION HREF="../Body/e_tp_err.htm#type-error"><B>TYPE-ERROR</B></A><P>
|
|
doesn't seem quite appropriate here. One idea is not to say, just let it<P>
|
|
be any subtype of <A REL=DEFINITION HREF="../Body/a_error.htm#error"><B>ERROR</B></A>. Another idea is to produce the result object<P>
|
|
and then signal a <A REL=DEFINITION HREF="../Body/e_tp_err.htm#type-error"><B>TYPE-ERROR</B></A> that this object doesn't match the<P>
|
|
type-specifier for the result type.<P>
|
|
<P>
|
|
Cassels points out that two similar operations are defined in CLtL to be<P>
|
|
inconsistent with each other:<P>
|
|
<P>
|
|
(replace (<A REL=DEFINITION HREF="../Body/f_mk_ar.htm#make-array"><B>make-array</B></A> 4) #(1 2 3)) just picks the shortest length, and<P>
|
|
"the extra elements near the end of the longer subsequence are not<P>
|
|
involved in the operation" so the result is #(1 2 3 <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A>)<P>
|
|
<P>
|
|
#4(1 2 3) duplicates the last element, so it's like #(1 2 3 3)<P>
|
|
#2(1 2 3) "is an error".<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>
|