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