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

[Christophe Rhodes]

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.

> 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