[cdr-discuss] What about CDR 3, then?

[Christophe Rhodes]

[ I think I basically agree with you; some comments below ]

Pascal Costanza <pc at 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