Forum: Editorial
References: UPGRADED-ARRAY-ELEMENT-TYPE, MAKE-ARRAY
Category: CLARIFICATION/CHANGE
Edit history: 2004-07-20, Version 1 by Bruno Haible
Status: For CLiki consideration
- Problem Description:
- CLHS 15.1.2.1 and UPGRADED-ARRAY-ELEMENT-TYPE imply that all implementations must support arrays of element type NIL. These are strange beasts: On one hand they are (if one dimensional) STRINGs. On the other hand any AREF access to an element must give an error, because there is no object of type nil. Thus they don't behave like normal arrays or sequences.
- Proposal (ARRAY-ELEMENT-TYPE-NIL:EXCLUDE):
- Modify the semantics of UPGRADED-ARRAY-ELEMENT-TYPE so that its behavior on the type NIL (or any equivalent type) is unspecified. In particular, it need not be the case that (UPGRADED-ARRAY-ELEMENT-TYPE NIL) must be a subtype of (UPGRADED-ARRAY-ELEMENT-TYPE foo) for any type foo.
- Test case:
- Rationale:
- These arrays are useless, and requiring them prevents an implementation from having certain efficient representations of strings.
- Current practice:
- CLISP and SBCL now implement arrays of element type NIL, but with small differences in the details, such as printing such arrays.
- Cost to Implementors:
- None.
- Cost to Users:
- None.
- Cost of Non-Adoption:
- NIL arrays imply that STRING and BASE-STRING are different types, which prevents an implementation from making the assumption that all strings have the same element type.
- Benefits:
- Eliminates silliness, and allows implementations to have more efficient strings.
- Aesthetics:
- Discussion:
- The "Cost to Implementors" cannot be "None" as there are implementations that do not support arrays with element type NIL.
"Cost to implementors" usually means the cost of adopting the proposed change. Since this proposal would make the definition of such arrays have undefined behavior, how would this cause work for developers of a (non-conforming!) implementation that does not currently support them?