[ 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