Absence of tests meant that a prior simplification (revision
17945c81f9) removed the ability to
inherit simultaneously from SEQUENCE and FUNCTION, breaking example
code in the extensible sequences ILC paper. Restore this, attempting
to explain various things about the current system in response to a
comment, and include tests to hopefully preserve subclassing of
FUNCTION, SEQUENCE and STREAM independently of each other.
Additionally fix the COERCE transform to transform into sequence
coercion if the type argument names an extended sequence class.
Fixes lp#2050088
The following code failed:
(sb-sequence:with-sequence-iterator-functions
(next stop value _set _index _copy)
('(a b c d) :from-end t)
(loop until (stop) collect (value) do (next)))
... with the following error:
The value
(D)
is not of type
NUMBER
when binding SB-KERNEL::X
[Condition of type TYPE-ERROR]
* Previously, MAKE-SEQUENCE expanded RESULT-TYPE while MAP, MERGE and
CONCATENATE did not.
* WHEN-EXTENDED-SEQUENCE-TYPE helps doing this without code duplication.
It passed (class-of result-prototype) to MAKE-SEQUENCE which, in the
best case, would go back to the prototype of the class and call
SEQUENCE:MAKE-SEQUENCE-LIKE on it.
All subtype queries and whatnot performed by MAKE-SEQUENCE before
finally calling SEQUENCE:MAKE-SEQUENCE-LIKE are unnecessary in the
common case of SEQUENCE:MAP being called from MAP in which case the
result type is an extended sequence.
Instead, directly call SEQUENCE:MAKE-SEQUENCE-LIKE on RESULT-PROTOTYPE.
This is what SEQUENCE:{CONCATENATE,MERGE} already do.
For the following situation:
- result type is a type specifier designating a DEFTYPEd type
- the type expands to a the name of a user-defined sequence class
- not all mandatory sequence protocol methods are define for the
user-define sequence class
MAKE-SEQUENCE used to signal a SIMPLE-TYPE-ERROR referring to the
unexpanded type specifier, instead of signaling a
SEQUENCE:PROTOCOL-UNIMPLEMENTED error.
Fixes lp#1315846.
