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

[Pascal Costanza]

On 6 Dec 2006, at 08:41, Christophe Rhodes wrote:

> Pascal Costanza <pc at 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 at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium