Duane Rettig  <duane@franz.com> wrote:
+---------------
| Actually, it is not possible to implement a-u-e-t completely
| correctly, as is listed here:
|   http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications
| and as described here:
|   http://www.cliki.net/Issue%20ARRAY-UPGRADING-UNDECIDABLE
+---------------

Thanks for those references!

+---------------
| Also, as for type NIL, it is not clear from the spec whether it is
| legal to upgrade NIL to BIT, since an array of type NIL is, under one
| interpretation, a string!  Witness:
| 
| http://www.cliki.net/Issue%20ARRAY-ELEMENT-TYPE-NIL
+---------------

Yup. CLISP at least upgrades NIL to BIT consistently:

    [1]> (upgraded-array-element-type nil)
    BIT
    [2]> (make-array 0 :element-type nil)
    #*
    [3]> (array-element-type *)
    BIT
    [4]> 

while CMUCL is somewhat inconsistent in its treatment:

    cmu> (upgraded-array-element-type nil)

    BIT
    cmu> (make-array 0 :element-type nil)

    ""
    cmu> (array-element-type *)

    BASE-CHAR
    cmu> 


-Rob

p.s. I also found CMUCL somewhat inconsistent in its treatment
of FIXNUM versus (SIGNED-BYTE 30):

    cmu> (upgraded-array-element-type '(signed-byte 30))

    FIXNUM
    cmu> (make-array 5 :element-type 'fixnum)

    #(0 0 0 0 0)
    cmu> (array-element-type *)

    (SIGNED-BYTE 30)
    cmu> 

Since UPGRADED-ARRAY-ELEMENT-TYPE is supposed to return "the most
specialized array representation capable of holding items of the
type denoted by [the] typespec", I would expect that:

    (array-element-type (make-array 5 :element-type '(signed-byte 30)))
      ==> FIXNUM

but in CMUCL it doesn't. Though perhaps this provides some justification?

    cmu> (subtypep 'fixnum '(signed-byte 30))

    T
    T
    cmu> (subtypep '(signed-byte 30) 'fixnum)

    T
    T
    cmu> 

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607