Pascal Costanza <pc@p-cos.net> writes:
My suggestion to resolve this is as follows: Instead of just removing the "must signal an error of type type-error" requirement, it should be made more specific what the consequences are when the types are not list or vector, roughly as follows.
- If the given type is not a recognizable subtype of sequence, then an error of type type-error is signaled. - If the given type is a recognizable subtype of sequence, but neither a recognizable subtype of list, nor a recognizable subtype of vector, the consequences are unspecified.
I think there are some more corner cases of what I think is the original intent that I would like to preserve. I'd replace the first three paragraphs of the proposal proper with: \paragraph{Proposal \texttt{(CONCATENATE-SEQUENCE-AGAIN:GENERALIZE)}:} \begin{itemize} \item Remove from \cl{make-sequence}, \cl{merge}, \cl{map} and \cl{concatenate} the requirement that ``An error [of type \cl{type-error}] must be signaled if the result-type is neither a recognizable subtype of \cl{list}, nor a recognizable subtype of \cl{vector}.'' \item Specify that if a type specifier is not a \recsub{} of \cl{sequence}, or is a \recsub{} of \texttt{(or list vector)} but not of either \cl{list} or \cl{vector}, then an error [of type \cl{type-error}] must be signaled. \item Specify that if a type specifier is a \recsub{} of \cl{sequence}, but not a \recsub{} of any of the types \texttt{(or list vector)}, \cl{list} or \cl{vector}, then the consequences are unspecified. \end{itemize} The square brackets above reflect the slightly different error requirements on the five functions affected; the intent of this proposal is to preserve the original requirements. \paragraph{Rationale:} This allows implementors to make extensions of \cl{sequence}, as seems to have been the original intent. \paragraph{Test Case:} No portable test case. In implementations extending the \cl{sequence} class, \begin{verbatim} (make-sequence '<sequence-class> 8) \end{verbatim} need not signal an error under this proposal. (Apologies for the use of TeX; I've put a formatted copy of the document with this and some minor typographical changes up at <http://www-jcsu.jesus.cam.ac.uk/~csr21/tmp/concatenate-sequence-again.pdf>) Pascal, does that address your concern? Does anyone else have a comment? I'm minded to make that document version two of CDR 3, if I don't hear adverse commentary. Cheers, Christophe