Hi, I have plans to modify CDR 3 slightly, adding a non-portable test case to the Test Case section and improving the references. I appreciate that the issue that CDR 3 describes is largely theoretical, but are there any comments from anyone out there? Getting any feedback before the finalization date would obviously be useful; it may be a theoretical issue at the moment but I hope that it will become a practical issue in the not-distant future. Cheers, Christophe
Christophe Rhodes <csr21@cantab.net> writes:
to the Test Case section and improving the references. I appreciate that the issue that CDR 3 describes is largely theoretical, but are there any comments from anyone out there? Getting any feedback before
At least LENGTH suffers from a similar problem: it is definied to work on "proper sequences", which are defined to be either vectors or proper lists. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
Nikodemus Siivola <nikodemus@random-state.net> writes:
Christophe Rhodes <csr21@cantab.net> writes:
to the Test Case section and improving the references. I appreciate that the issue that CDR 3 describes is largely theoretical, but are there any comments from anyone out there? Getting any feedback before
At least LENGTH suffers from a similar problem: it is definied to work on "proper sequences", which are defined to be either vectors or proper lists.
Thanks for raising this; I hadn't spotted it, and it affects ELT too. However, the error terminology specified by ANSI is slightly different: where MAKE-SEQUENCE and friends has "must be signalled" if the specifier isn't a subtype of list or vector, LENGTH and ELT have "should be prepared to signal", which is close enough to a weasel word that I can live with it. Having said that, what I plan to do for the forthcoming extensible sequences, to maximize cultural compatibility with this clause is to define default methods on SEQUENCE for the generic versions of ELT, (SETF ELT) and LENGTH, which signal a type error. Then it is the user of the facility, by overriding those generic functions for his own sequence class, who explicitly requests the type-error from ELT / (SETF ELT) / LENGTH not to be signalled, and then probably even the language lawyers are happy. Cheers, Christophe
On 23 Nov 2006, at 21:53, Christophe Rhodes wrote:
Hi,
I have plans to modify CDR 3 slightly, adding a non-portable test case to the Test Case section and improving the references. I appreciate that the issue that CDR 3 describes is largely theoretical, but are there any comments from anyone out there? Getting any feedback before the finalization date would obviously be useful; it may be a theoretical issue at the moment but I hope that it will become a practical issue in the not-distant future.
[I am posting this as a regular Common Lisper, not as a CDR editor.] I have just read your proposal and the respective original CONCATENATE-SEQUENCE issue in the HyperSpec. Apart from the fact that I have a hard time imagining what other interesting implementations one could have for sequences with fixed length apart from lists and vectors, I also have a hard time to imagine how sequences with non-fixed lengths could be integrated, for example with concatenate-sequence. To be more concrete: You could regard lazy lists and streams as kinds of sequences, and they could indeed be made subtypes of 'sequence. In those cases, though, it doesn't make a lot of sense that concatenate- sequence supports them, for example, especially when they model infinite sequences (like "all prime numbers", or so). I think a different way to say this is as the following question: What guarantees do the existing sequence functions give us? For example, do they have to terminate? What other kinds of subtypes of sequence do you have in mind? Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium
Pascal Costanza <pc@p-cos.net> writes:
To be more concrete: You could regard lazy lists and streams as kinds of sequences, and they could indeed be made subtypes of 'sequence. In those cases, though, it doesn't make a lot of sense that concatenate- sequence supports them, for example, especially when they model infinite sequences (like "all prime numbers", or so).
I agree that infinite sequences aren't amenable to being termed CL sequences, because one of the things that a CL sequence has is a length, which must be a non-negative integer. So, indeed, things with infinite size aren't sequences. But that doesn't stop all sorts of other things from being sequences: even a class of lazy list which knows its length (but not its elements) in advance. I don't know how useful one of the latter would be, I admit.
I think a different way to say this is as the following question: What guarantees do the existing sequence functions give us? For example, do they have to terminate?
Yes, modulo the usual constraints about the resource limits of the physical hardware that might prevent them from doing so.
What other kinds of subtypes of sequence do you have in mind?
Briefly, off the top of my head: other sequential data structures, such as doubly-linked lists, queues, hash-consed lists and flexichains; then also application-specific data structures, such as editor buffers, HTML DOM elements in a document, compiler blocks in an intermediate representation for a program; maybe also system objects like memory-mapped files. I could probably go on :-) The point of making these sequences is that then these objects can be used as arguments to the standard CL functions: you don't have to reimplement the whole (or even part) of the sequence library yourself; you can simply call functions which express what you mean. (In some cases above, some sequence operations may not make conceptual sense -- for instance, you're unlikely to want to call SORT on compiler blocks -- but that's not to say that the operation doesn't make sense on the data structure itself, only on its contents when considered semantically from the application point of view.) I have prepared a paper discussing these and other issues (including implementational issues) whose publication I am trying to arrange; when I hear back from the ILC program committee about my grossly over-the-page-limit proposal, I may be in a position to disseminate code and documentation more widely. Cheers, Christophe
Hi Christophe, As an open ended question: how does this CDR relate to Marco Antoniotti's CL-Enumerations and my CL-Containers? From an implementation point of view, it sounds like you would need to make the various CL functions into generic functions and/or write a lot of code that dispatches on type within the CL functions. thanks, On Dec 3, 2006, at 9:50 AM, Christophe Rhodes wrote:
Pascal Costanza <pc@p-cos.net> writes:
To be more concrete: You could regard lazy lists and streams as kinds of sequences, and they could indeed be made subtypes of 'sequence. In those cases, though, it doesn't make a lot of sense that concatenate- sequence supports them, for example, especially when they model infinite sequences (like "all prime numbers", or so).
I agree that infinite sequences aren't amenable to being termed CL sequences, because one of the things that a CL sequence has is a length, which must be a non-negative integer. So, indeed, things with infinite size aren't sequences. But that doesn't stop all sorts of other things from being sequences: even a class of lazy list which knows its length (but not its elements) in advance. I don't know how useful one of the latter would be, I admit.
I think a different way to say this is as the following question: What guarantees do the existing sequence functions give us? For example, do they have to terminate?
Yes, modulo the usual constraints about the resource limits of the physical hardware that might prevent them from doing so.
What other kinds of subtypes of sequence do you have in mind?
Briefly, off the top of my head: other sequential data structures, such as doubly-linked lists, queues, hash-consed lists and flexichains; then also application-specific data structures, such as editor buffers, HTML DOM elements in a document, compiler blocks in an intermediate representation for a program; maybe also system objects like memory-mapped files. I could probably go on :-)
The point of making these sequences is that then these objects can be used as arguments to the standard CL functions: you don't have to reimplement the whole (or even part) of the sequence library yourself; you can simply call functions which express what you mean. (In some cases above, some sequence operations may not make conceptual sense -- for instance, you're unlikely to want to call SORT on compiler blocks -- but that's not to say that the operation doesn't make sense on the data structure itself, only on its contents when considered semantically from the application point of view.)
I have prepared a paper discussing these and other issues (including implementational issues) whose publication I am trying to arrange; when I hear back from the ILC program committee about my grossly over-the-page-limit proposal, I may be in a position to disseminate code and documentation more widely.
Cheers,
Christophe _______________________________________________ cdr-discuss mailing list cdr-discuss@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cdr-discuss
-- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM
Gary King <gwking@metabang.com> writes:
As an open ended question: how does this CDR relate to Marco Antoniotti's CL-Enumerations and my CL-Containers? From an implementation point of view, it sounds like you would need to make the various CL functions into generic functions and/or write a lot of code that dispatches on type within the CL functions.
I'm not Christophe, but as far as I can see CDR 3 says nothing about extensible sequences per se, but rather treats a few spec bugs that effectively prevent implementation of any sort of sequences that are not (OR VECTOR LIST). Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
Gary King <gwking@metabang.com> writes:
As an open ended question: how does this CDR relate to Marco Antoniotti's CL-Enumerations and my CL-Containers?
I don't think this CDR relates at all to cl-enumerations or cl-containers.
From an implementation point of view, it sounds like you would need to make the various CL functions into generic functions and/or write a lot of code that dispatches on type within the CL functions.
CDR 3 does not discuss anything like this; in some sense I'm sorry that I have muddied the waters in my answer to Pascal. Just to reiterate: CDR 3 addresses what I believe to be a specification bug that I discovered in the course of performing related work. That said, yes, I have performed some related work which makes various operations generic, both in the pre-CLOS sense and in the generic function sense; I don't think it's a lot of code, and I don't believe that there are other negative implications. This work will not be incompatible, as far as I can tell, with either cl-enumerations or cl-containers; I feel I can say that because this work should not be incompatible with any existing code. (Without a more directed question, I'm not sure that I can give you a clearer answer. If you do have a question, it might help to know that documentation of the form "this is like X in Java", or, worse, "this is a list of the symbols in this package", is not enough context to give me confidence in my answers). Cheers, Christophe
Hi again, On Dec 5, 2006, at 11:41 AM, Christophe Rhodes wrote:
I don't think this CDR relates at all to cl-enumerations or cl-containers.
My bad. I actually read CDR 3 a few weeks ago but forgot that it is focused on a specific area in my excitement regarding general iteration, etc... -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM
Hi, OK, I have understood your response to my reply, and as far as I can tell, your (Christophe's) reasoning is sound, both in your response to my and to Gary's comments so far. Still, I had the somewhat nagging feeling that there is some deeper issue involved here, and I think I am getting closer (although I am not 100% sure yet). So here is my current take on this: In CDR 3 you relax a restriction stated in ANSI CL. However, you may have gone too far here, in the sense that after accepting CDR 3, it may not be clear anymore what sequences actually are. To put it as a question: Which subset of the functions defined in the Sequence Dictionary must a subtype of sequence implement? Is it allowed to signal errors for some functions? May these functions have undefined consequences? Under what circumstances? For example, must LENGTH always return a number? Or take COPY-SEQ: The HyperSpec clearly specifies what happens for lists and for vectors. What happens here for other sequences? As long as the only kinds of sequences that can be created are lists and vectors, there is no ambiguity here. Once this becomes explicitly open for arbitrary extensions - then what? Don't you have to define a number of constraints on the possible subtypes of sequence that are not lists or vectors here? Pascal P.S.: Please don't understand this as an attack. I am just trying to shake the tree to see what falls out. ;) -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium
Pascal Costanza <pc@p-cos.net> writes:
Still, I had the somewhat nagging feeling that there is some deeper issue involved here, and I think I am getting closer (although I am not 100% sure yet).
Excellent.
So here is my current take on this:
In CDR 3 you relax a restriction stated in ANSI CL. However, you may have gone too far here, in the sense that after accepting CDR 3, it may not be clear anymore what sequences actually are.
Actually, again, I'm not sure that CDR 3 is relevant here, because ANSI already says that LIST and VECTOR is not necessarily an exhaustive partition of SEQUENCE; CDR 3 just tries to make that consistent with other pieces of the puzzle.
To put it as a question: Which subset of the functions defined in the Sequence Dictionary must a subtype of sequence implement? Is it allowed to signal errors for some functions? May these functions have undefined consequences? Under what circumstances? For example, must LENGTH always return a number?
Or take COPY-SEQ: The HyperSpec clearly specifies what happens for lists and for vectors. What happens here for other sequences?
These are good questions, and ones that CDR 3 isn't attempting to address. However, the good news is that you can now download SBCL CVS HEAD and play with my ideas written out in code (though not yet in specification); see <http://article.gmane.org/gmane.lisp.steel-bank.devel/8132> for a brief introduction. (But, to reiterate: I don't think this is directly relevant to CDR 3, except that it depends on the loosened behaviour of CDR 3 for make-sequence&friends).
As long as the only kinds of sequences that can be created are lists and vectors, there is no ambiguity here. Once this becomes explicitly open for arbitrary extensions - then what? Don't you have to define a number of constraints on the possible subtypes of sequence that are not lists or vectors here?
I think that an implementation providing a non-list non-vector sequence would have to document its behaviour, so it falls in the realm of language extension or implementation-defined behaviour.
P.S.: Please don't understand this as an attack. I am just trying to shake the tree to see what falls out. ;)
Oh, not at all; on the contrary, thank you for thinking about this. Cheers, Christophe
On 6 Dec 2006, at 08:41, Christophe Rhodes wrote:
Pascal Costanza <pc@p-cos.net> writes:
Still, I had the somewhat nagging feeling that there is some deeper issue involved here, and I think I am getting closer (although I am not 100% sure yet).
Excellent.
So here is my current take on this:
In CDR 3 you relax a restriction stated in ANSI CL. However, you may have gone too far here, in the sense that after accepting CDR 3, it may not be clear anymore what sequences actually are.
Actually, again, I'm not sure that CDR 3 is relevant here, because ANSI already says that LIST and VECTOR is not necessarily an exhaustive partition of SEQUENCE; CDR 3 just tries to make that consistent with other pieces of the puzzle.
To put it as a question: Which subset of the functions defined in the Sequence Dictionary must a subtype of sequence implement? Is it allowed to signal errors for some functions? May these functions have undefined consequences? Under what circumstances? For example, must LENGTH always return a number?
Or take COPY-SEQ: The HyperSpec clearly specifies what happens for lists and for vectors. What happens here for other sequences?
These are good questions, and ones that CDR 3 isn't attempting to address. However, the good news is that you can now download SBCL CVS HEAD and play with my ideas written out in code (though not yet in specification); see <http://article.gmane.org/gmane.lisp.steel-bank.devel/8132> for a brief introduction. (But, to reiterate: I don't think this is directly relevant to CDR 3, except that it depends on the loosened behaviour of CDR 3 for make-sequence&friends).
As long as the only kinds of sequences that can be created are lists and vectors, there is no ambiguity here. Once this becomes explicitly open for arbitrary extensions - then what? Don't you have to define a number of constraints on the possible subtypes of sequence that are not lists or vectors here?
I think that an implementation providing a non-list non-vector sequence would have to document its behaviour, so it falls in the realm of language extension or implementation-defined behaviour.
OK, it's still the case that you are only relaxing the requirements, but you are not making it explicit what it means when some code it outside of the domain of lists and vectors. With the current ANSI CL spec, a conforming program can rely on the fact that the functions in the Sequence Dictionary always work as expected when the objects passed are of type sequence (!). With your current formulation, it's not clear what can and cannot be relied on. 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. According to the ANSI CL error terminology (Section 1.4.2 Error Terminology), this makes it very explicit that extensions of sequence fall in the domain of language extensions and gives conforming programs a reliable test under what circumstances the sequence functions are guaranteed to behave as documented (I am not 100% sure about the latter here). Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium
[ I think I basically agree with you; some comments below ] Pascal Costanza <pc@p-cos.net> writes:
I think that an implementation providing a non-list non-vector sequence would have to document its behaviour, so it falls in the realm of language extension or implementation-defined behaviour.
OK, it's still the case that you are only relaxing the requirements, but you are not making it explicit what it means when some code it outside of the domain of lists and vectors. With the current ANSI CL spec, a conforming program can rely on the fact that the functions in the Sequence Dictionary always work as expected when the objects passed are of type sequence (!).
Up to a point. Depending on how carefully you read, you might find that in fact some or most of them are implicitly defined only on lists and vectors, in wording that is new since CLtL2 (and apparently editorial rather than decided upon in an issue).
With your current formulation, it's not clear what can and cannot be relied on.
This I agree with.
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 this is probably close to my intent, and would make no current implementation non-conforming; if I may, I will use wording similar to this in a revision of CDR 3. Thanks, Christophe
On 6 Dec 2006, at 11:12, Christophe Rhodes wrote:
[ I think I basically agree with you; some comments below ]
Pascal Costanza <pc@p-cos.net> writes:
I think that an implementation providing a non-list non-vector sequence would have to document its behaviour, so it falls in the realm of language extension or implementation-defined behaviour.
OK, it's still the case that you are only relaxing the requirements, but you are not making it explicit what it means when some code it outside of the domain of lists and vectors. With the current ANSI CL spec, a conforming program can rely on the fact that the functions in the Sequence Dictionary always work as expected when the objects passed are of type sequence (!).
Up to a point. Depending on how carefully you read, you might find that in fact some or most of them are implicitly defined only on lists and vectors, in wording that is new since CLtL2 (and apparently editorial rather than decided upon in an issue).
OK, apparently my wording wasn't very clear. What I meant is this: Actually just because these functions are defined only on lists and vectors _and_ the only kinds of sequences you can create in ANSI CL are lists and vectors, everything is well-specified.
With your current formulation, it's not clear what can and cannot be relied on.
This I agree with.
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 this is probably close to my intent, and would make no current implementation non-conforming; if I may, I will use wording similar to this in a revision of CDR 3.
Please feel free to do so. I am not sure whether implementations that adopt CDR 3 would still be conforming, though. The error terminology in ANSI CL implies that conforming programs can rely on the fact that sequence functions signal errors when they are passed what are neither lists nor vectors. With CDR 3, they cannot rely on this anymore. But that's actually the whole point of CDR 3, as far as I understand it. Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium
Pascal Costanza <pc@p-cos.net> writes:
OK, apparently my wording wasn't very clear. What I meant is this: Actually just because these functions are defined only on lists and vectors _and_ the only kinds of sequences you can create in ANSI CL are lists and vectors, everything is well-specified.
Not quite. Implementations are allowed to have eg. MAKE-FOO-SEQUENCE that returns objects of type SEQUENCE, which are neither vectors nor lists, and all functions defined to work on sequences are required to work on such objects. The upshot is that while a portable program cannot construct a non-portable sequence object, eg. portable libraries should be written to deal with generic sequences as well -- and this is just plain ANSI. Granted, no such extended sequences have traditionally exited, but that is not what the spec says. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
On 6 Dec 2006, at 17:11, Nikodemus Siivola wrote:
Pascal Costanza <pc@p-cos.net> writes:
OK, apparently my wording wasn't very clear. What I meant is this: Actually just because these functions are defined only on lists and vectors _and_ the only kinds of sequences you can create in ANSI CL are lists and vectors, everything is well-specified.
Not quite. Implementations are allowed to have eg.
MAKE-FOO-SEQUENCE
that returns objects of type SEQUENCE, which are neither vectors nor lists, and all functions defined to work on sequences are required to work on such objects.
The upshot is that while a portable program cannot construct a non-portable sequence object, eg. portable libraries should be written to deal with generic sequences as well -- and this is just plain ANSI.
Granted, no such extended sequences have traditionally exited, but that is not what the spec says.
OK, good point. Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium
Pascal Costanza <pc@p-cos.net> writes:
On 6 Dec 2006, at 11:12, Christophe Rhodes wrote:
[ I think I basically agree with you; some comments below ]
Pascal Costanza <pc@p-cos.net> writes:
I think that an implementation providing a non-list non-vector sequence would have to document its behaviour, so it falls in the realm of language extension or implementation-defined behaviour.
OK, it's still the case that you are only relaxing the requirements, but you are not making it explicit what it means when some code it outside of the domain of lists and vectors. With the current ANSI CL spec, a conforming program can rely on the fact that the functions in the Sequence Dictionary always work as expected when the objects passed are of type sequence (!).
Up to a point. Depending on how carefully you read, you might find that in fact some or most of them are implicitly defined only on lists and vectors, in wording that is new since CLtL2 (and apparently editorial rather than decided upon in an issue).
OK, apparently my wording wasn't very clear. What I meant is this: Actually just because these functions are defined only on lists and vectors _and_ the only kinds of sequences you can create in ANSI CL are lists and vectors, everything is well-specified.
I didn't understand this from your post, and in fact I think this way of looking at things is in error. I believe that the majority of the functions in the Sequences chapter of ANSI CL are in fact specified to work on sequences, not on objects of type (or list vector): if you pass a sequence of whatever type to FIND, POSITION, COUNT, DELETE, REMOVE, SORT, SUBSTITUTE, and so on, then it should work as expected. The exceptions are: * MAKE-SEQUENCE, MERGE, MAP, COERCE and CONCATENATE. In this case, in fact, any sequence argument can be an arbitrary sequence; it is purely the _type specifier_ argument which must designate a subtype of list or a subtype of vector. It is this restriction on the type specifier that I am attempting to remove in CDR 3. * ELT, (SETF ELT) and LENGTH. As pointed out by Nikodemus, these functions formally accept a /proper sequence/, which the glossary defines as a proper list or a vector, and also as a sequence which is not an improper list. These two definitions are the same if sequence is just (or list vector), but I think the intent is clear in the case where there are more kinds of sequences, so I haven't worried about this case too much.
I am not sure whether implementations that adopt CDR 3 would still be conforming, though. The error terminology in ANSI CL implies that conforming programs can rely on the fact that sequence functions signal errors when they are passed what are neither lists nor vectors. With CDR 3, they cannot rely on this anymore.
But that's actually the whole point of CDR 3, as far as I understand it.
CDR 3 raises a single case where a program could tell the difference between a CDR-3-supporting implementation and a straight ANSI CL one: where a designator for a non-list non-vector sequence type is passed to the MAKE-SEQUENCE family of functions. However, this test case (as described in the document, or possibly only in my draft for an update; I reproduce it below[*]) only makes a difference in implementations which extend the sequence type: which is currently zero implementations, unless you count my experimental SBCL code. So, in that sense, yes, there is a distinction between CDR 3 and not, but it is not one that has arisen in practice until now. [*] In an implementation not supporting CDR 3, (assert (typep (ignore-errors (make-sequence *x* 8)) '(or list vector))) will never trigger the assertion, no matter what *X* is. In an implementation supporting CDR 3, the assertion /may/ be triggered if other elements of the implementation are so arranged: including allowing other sequence types. Cheers, Christophe
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
On 13 Dec 2006, at 20:35, Christophe Rhodes wrote:
\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.
How can something be a recognized subtype of (or list vector) but not of either list or vector?!?
Pascal, does that address your concern?
Apart from that, your changes look good to me.
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.
Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium
Pascal Costanza <pc@p-cos.net> writes:
On 13 Dec 2006, at 20:35, Christophe Rhodes wrote:
\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.
How can something be a recognized subtype of (or list vector) but not of either list or vector?!?
For example, (or list string) is a subtype of (or list vector) but not of either list or vector. Cheers, Christophe
On 13 Dec 2006, at 23:11, Christophe Rhodes wrote:
Pascal Costanza <pc@p-cos.net> writes:
On 13 Dec 2006, at 20:35, Christophe Rhodes wrote:
\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.
How can something be a recognized subtype of (or list vector) but not of either list or vector?!?
For example, (or list string) is a subtype of (or list vector) but not of either list or vector.
Ah. ;) Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium
Christophe Rhodes <csr21@cantab.net> writes:
\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.
While this is strictly speaking sufficient, I would suggest quoting chapter and verse for "uspecified consequences", since it is far too often confused with "undefined consequences". Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
participants (4)
-
Christophe Rhodes -
Gary King -
Nikodemus Siivola -
Pascal Costanza