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

[Christophe Rhodes]

Pascal Costanza <pc at p-cos.net> writes:

> On 6 Dec 2006, at 11:12, Christophe Rhodes wrote:
>
>> [ 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).
>
> OK, apparently my wording wasn't very clear. What I meant is this:
> Actually just because these functions are defined only on lists and
> vectors _and_ the only kinds of sequences you can create in ANSI CL
> are lists and vectors, everything is well-specified.

I didn't understand this from your post, and in fact I think this way
of looking at things is in error.

I believe that the majority of the functions in the Sequences chapter
of ANSI CL are in fact specified to work on sequences, not on objects
of type (or list vector): if you pass a sequence of whatever type to
FIND, POSITION, COUNT, DELETE, REMOVE, SORT, SUBSTITUTE, and so on,
then it should work as expected.

The exceptions are:

* MAKE-SEQUENCE, MERGE, MAP, COERCE and CONCATENATE.  In this case, in
  fact, any sequence argument can be an arbitrary sequence; it is
  purely the _type specifier_ argument which must designate a subtype
  of list or a subtype of vector.  It is this restriction on the type
  specifier that I am attempting to remove in CDR 3.

* ELT, (SETF ELT) and LENGTH.  As pointed out by Nikodemus, these
  functions formally accept a /proper sequence/, which the glossary
  defines as a proper list or a vector, and also as a sequence which
  is not an improper list.  These two definitions are the same if
  sequence is just (or list vector), but I think the intent is clear
  in the case where there are more kinds of sequences, so I haven't
  worried about this case too much.

> I am not sure whether implementations that adopt CDR 3 would still be
> conforming, though. The error terminology in ANSI CL implies that
> conforming programs can rely on the fact that sequence functions
> signal errors when they are passed what are neither lists nor
> vectors. With CDR 3, they cannot rely on this anymore.
>
> But that's actually the whole point of CDR 3, as far as I understand it.

CDR 3 raises a single case where a program could tell the difference
between a CDR-3-supporting implementation and a straight ANSI CL one:
where a designator for a non-list non-vector sequence type is passed
to the MAKE-SEQUENCE family of functions.  However, this test case (as
described in the document, or possibly only in my draft for an update;
I reproduce it below[*]) only makes a difference in implementations
which extend the sequence type: which is currently zero
implementations, unless you count my experimental SBCL code.

So, in that sense, yes, there is a distinction between CDR 3 and not,
but it is not one that has arisen in practice until now.

[*] In an implementation not supporting CDR 3,
      (assert (typep (ignore-errors (make-sequence *x* 8)) '(or list vector)))
    will never trigger the assertion, no matter what *X* is.  In an
    implementation supporting CDR 3, the assertion /may/ be triggered
    if other elements of the implementation are so arranged: including
    allowing other sequence types.

Cheers,

Christophe