Return to Answer

This kind of analysis is not only theoritical, it actually happens with SBCL:

This kind of analysis is not only theoretical, it actually happens with SBCL:

At first, I thought that maybe we could exploit the apparent randomness of the array, like uninitialized arrays in C (don't do this), but this is clearly not possible, due to the fact that accessing uninitialized arrays has undefined consequences (see comments). Consequences are undefined even if the actual data is only referenced and not effectively used for its content, as in:

The example is taken from the "Issue UNINITIALIZED-ELEMENTS Writeup": even though is wouldn't be surprising if aref and list only moved or copied data without needing to know what it contains (e.g. by making bitwise copy), the specification clearly says that consequences are undefined when aref is used to access elements of type nil.

And then, I see no reason to allow the creation of arrays of type NIL in the first place, apart maybe from allocating (useless?) memory. As said above, maybe there is an implementation-specific, totally not portable way for some lisp to use such arrays, and pass them to foreign functions, but I doubt it.

Accessing uninitialized arrays has undefined consequences (see comments). Consequences are undefined even if the actual data is only referenced and not effectively used for its content, as in:

The example is taken from the "Issue UNINITIALIZED-ELEMENTS Writeup".

I see no reason to allow the creation of arrays of type NIL in the first place, apart maybe from allocating (useless?) memory. As said above, maybe there is an implementation-specific, totally not portable way for some lisp to use such arrays, and pass them to foreign functions, but I doubt it.

The NIL type means: this functions will not return successively. For example, in SBCL, the error function has the following declared type:

NIL implies the absence of "normal" termination. If the body of your function is (loop), the return type is also NIL. But sometimes you can return normally but you do not have any value to return (like void in C). That is why (values &optional) is more appropriate as a type declaration when you return no value successively. This is done by using the (values) expression in your code. The &optional keyword in the type declaration is necessary because the type (values) would allow you to return more values (see comments).

The NIL type means: this functions will not return successfully. For example, in SBCL, the error function has the following declared type:

NIL implies the absence of "normal" termination. If the body of your function is (loop), the return type is also NIL. But sometimes you can return normally but you do not have any value to return (like void in C). That is why (values &optional) is more appropriate as a type declaration when you return no value successfully. This is done by using the (values) expression in your code. The &optional keyword in the type declaration is necessary because the type (values) would allow you to return more values (see comments).