While looking at one of the ANSI test in clocc
(clocc.sourceforge.net), I was wondering what this is supposed to do:
(make-sequence '(simple-array (unsigned-byte 8)) 4)
and a related expression
(coerce '(1 2 3 4) '(simple-array (unsigned-byte 8)))
The CLHS entry for make-sequence says the type should be a sequence
type-specifier. But (simple-array (unsigned-byte 8)) isn't a subtype
of sequence. However, the (simple-array (unsigned-byte 8) (*)) is a
subtype of the desired type and is a subtype of sequence.
I think this leaves a little bit of room for interpretation. ACL and
Clisp create the sequence, CMUCL doesn't. I think CMUCL is ok, but a
better answer is to create the array.
For coerce, ACL and Clisp also create the array, but CMUCL doesn't.
However, since (simple-array (unsigned-byte 8) (*)) clearly is a
subtype of the desired type, I think CMUCL is wrong in this case and
ACL and Clisp are right.
Is this right?
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
> (make-sequence '(simple-array (unsigned-byte 8)) 4)
> (coerce '(1 2 3 4) '(simple-array (unsigned-byte 8)))
>
> The CLHS entry for make-sequence says the type should be a sequence
> type-specifier. But (simple-array (unsigned-byte 8)) isn't a subtype
> of sequence. However, the (simple-array (unsigned-byte 8) (*)) is a
> subtype of the desired type and is a subtype of sequence.
Where did that subtype come from? It might seem a useful choice in
this particular case, but it's not obvious how to extend the
specification to describe how to pick such subtypes. Actually, I
think it's quite reasonable for a sequence function to require a
sequence type and to provide error checking.
> I think this leaves a little bit of room for interpretation.
Actually, there's no room for interpretation: the Exceptional
Situations section says a TYPE-ERROR must be signalled. ACL and CLISP
are wrong here.
> For coerce, ACL and Clisp also create the array, but CMUCL doesn't.
> However, since (simple-array (unsigned-byte 8) (*)) clearly is a
> subtype of the desired type, I think CMUCL is wrong in this case and
> ACL and Clisp are right.
Again, how should COERCE pick a subtype?
Here the wording is looser, and it does seem possible to provide
compatible extensions to allow coercion to other types, so I don't
think ACL and Clisp are wrong. Such extensions should be documented,
though. Nevertheless, CMUCL is perfectly right: There's no
requirement to coerce to an array type that is not a recognizable
subtype of VECTOR.
--
Pekka P. Pirinen
It is easier to change the specification to fit the program than vice
versa. - Alan Perlis
>>>>> "Pekka" == Pekka P Pirinen <···············@globalgraphics.com> writes:
Pekka> Raymond Toy <···@rtp.ericsson.se> writes:
>> (make-sequence '(simple-array (unsigned-byte 8)) 4)
>> (coerce '(1 2 3 4) '(simple-array (unsigned-byte 8)))
>>
>> The CLHS entry for make-sequence says the type should be a sequence
>> type-specifier. But (simple-array (unsigned-byte 8)) isn't a subtype
>> of sequence. However, the (simple-array (unsigned-byte 8) (*)) is a
>> subtype of the desired type and is a subtype of sequence.
Pekka> Where did that subtype come from? It might seem a useful choice in
Which subtype? The (simple-array (unsigned-byte 8) (*))?
Pekka> this particular case, but it's not obvious how to extend the
Pekka> specification to describe how to pick such subtypes. Actually, I
Pekka> think it's quite reasonable for a sequence function to require a
Pekka> sequence type and to provide error checking.
>> I think this leaves a little bit of room for interpretation.
Pekka> Actually, there's no room for interpretation: the Exceptional
Pekka> Situations section says a TYPE-ERROR must be signalled. ACL and CLISP
Pekka> are wrong here.
Ok.
>> For coerce, ACL and Clisp also create the array, but CMUCL doesn't.
>> However, since (simple-array (unsigned-byte 8) (*)) clearly is a
>> subtype of the desired type, I think CMUCL is wrong in this case and
>> ACL and Clisp are right.
Pekka> Again, how should COERCE pick a subtype?
Pekka> Here the wording is looser, and it does seem possible to provide
Pekka> compatible extensions to allow coercion to other types, so I don't
Pekka> think ACL and Clisp are wrong. Such extensions should be documented,
Pekka> though. Nevertheless, CMUCL is perfectly right: There's no
Pekka> requirement to coerce to an array type that is not a recognizable
Pekka> subtype of VECTOR.
Ok. This makes sense.
Ray