Issue ARRAY-ELEMENT-TYPE-NIL

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?

I stand corrected. However, while it is true that making the proposed change would not require work by implementors not supporting the feature, I'd wager that there may still be some issues lurking when the implementors have to "fix" UPGRADED-ARRAY-ELEMENT-TYPE.

This page is linked from: Proposed ANSI Revisions and Clarifications  

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively