make-array does not check the validity of its :element-type argument

[hans]

"Version 1.2-r8284S (LinuxX8664)"

make-array does not verify that the :element-type is a valid type.

[gb]

It's not required to do so, doesn't seem to do so in other implementations, and it's not clear that it would be correct to do so.

If the :element-type is well-formed but unknown, should UPGRADED-ARRAY-ELEMENT-TYPE also signal an error ?

It seems as likely that someone has a forward-referenced type-specifier in code that's worked for years and works in other implementations (and gets screwed by the proposed change) than that someone gets screwed by misspelling a type specifer and getting an array of unexpected type. Neither case is well-defined, and I don't see a compelling reason for deviating from current practice (which happens to incidentally match the behavior of CMUCL and SBCL versions that I tested but of course may not match other implementations.)

[hans]

Clisp checks the element type:

Break 1 [3]> (make-array 20 :element-type 'foo)

*** - SUBTYPEP: invalid type specification FOO

So does Allegro:

USER(1): (make-array 20 :element-type 'foo) Error: Erroneous array element-type: FOO

[condition type: SIMPLE-ERROR]

[gb]

Checking is perfectly valid implementation-dependent behavior. Not checking is also perfectly valid implementation-dependent behavior. Checking in UPGRADED-ARRAY-ELEMENT-TYPE but not in a toplevel call to MAKE-ARRAY is somewhat inconsistent but perfectly valid implementation-dependent behavior. Deleting all of the files from your disk is malicious and stupid but otherwise valid implementation-dependent behavior. Behaving differently in compiled code than in the REPL is perfectly valid (and somewhat plausible) implementation-dependent behavior. If calling MAKE-ARRAY with an :ELEMENT-TYPE that's a recognizable subtype of BIT does not result in an array whose element-type is BIT, that's a bug, since the spec defines MAKE-ARRAY'S behavior in that case, and similarly for CHARACTER. How the implementation handles other type specifiers (including undefined type-specifiers) is not defined by the spec.

One could argue that checking for undefined type specifiers is "better" than silently promoting them to T, and there's obvious validity in that argument. Whether it's so much better that existing code that may silently depend on the current behavior in a particular implementation (this one) should break is not at all clear; I don't believe that it is.

[gz]

It sounds like a good compromise would be for the compiler to offer a warning if the type is unknown, but the runtime to continue to allow unknown types. The former will address usability issues in the vast majority of real cases, and the latter is a nod towards the legacy application issue.