Some type specifier lists denote specializations of data types named by symbols. These specializations may be reflected by more efficient representations in the underlying implementation. As an example, consider the type (array short-float). Implementation A may choose to provide a specialized representation for arrays of short floating-point numbers, and implementation B may choose not to.
If you should want to create an array for the express purpose of holding only short-float objects, you may optionally specify to make-array the element type short-float. This does not require make-array to create an object of type (array short-float); it merely permits it. The request is construed to mean “Produce the most specialized array representation capable of holding short-floats that the implementation can provide.” Implementation A will then produce a specialized array of type (array short-float), and implementation B will produce an ordinary array of type (array t).
If one were then to ask whether the array were actually of type (array short-float), implementation A would say “yes,” but implementation B would say “no.” This is a property of make-array and similar functions: what you ask for is not necessarily what you get.
X3J13 voted in January 1989 to eliminate the differing treatment of types when used “for discrimination” rather than “for declaration” on the grounds that implementors have not treated the distinction consistently and (which is more important) users have found the distinction confusing.
As a consequence of this change, the behavior of typep and subtypep on array and complex type specifiers must be modified. See the descriptions of those functions. In particular, under their new behavior, implementation B would say “yes,” agreeing with implementation A, in the discussion above.
Note that the distinction between declaration and discrimination remains useful, if only so that we may remark that the specialized (list) form of the function type specifier may still be used only for declaration and not for discrimination.
X3J13 voted in June 1988 to clarify that while the specialized form of the function type specifier (a list of the symbol function possibly followed by argument and value type specifiers) may be used only for declaration, the symbol form (simply the name function) may be used for discrimination.
The valid list-format names for data types are as follows:
Note that (array t) is a proper subset of (array *). The reason is that (array t) is the set of arrays that can hold any Common Lisp object (the elements are of type t, which includes all objects). On the other hand, (array *) is the set of all arrays whatsoever, including, for example, arrays that can hold only characters. Now (array character) is not a subset of (array t); the two sets are in fact disjoint because (array character) is not the set of all arrays that can hold characters but rather the set of arrays that are specialized to hold precisely characters and no other objects. To test whether an array foo can hold a character, one should not use
but rather
See array-element-type.
is still not a legitimate test of whether the array foo can hold a character; one must still say
to determine that question.
X3J13 also voted in January 1989 to specify that within the lexical scope of an array type declaration, it is an error for an array element, when referenced, not to be of the exact declared element type. A compiler may, for example, treat every reference to an element of a declared array as if the reference were surrounded by a the form mentioning the declared array element type (not the upgraded array element type). Thus
may be treated as
The declaration amounts to a promise by the user that the aref will never produce a value outside the interval 0 to 15, even if in that particular implementation the array element type (unsigned-byte 4) is upgraded to, say, (unsigned-byte 8). If such upgrading does occur, then values outside that range may in fact be stored in the-array, as long as the code in snarf-hex-digits never sees them.
As a general rule, a compiler would be justified in transforming
into
It may also make inferences involving more complex functions, such as position or find. For example, find applied to an array always returns either nil or an object whose type is the element type of the array.
X3J13 voted in January 1989 to change typep and subtypep so that the specialized array type specifier means the same thing for discrimination as for declaration: it encompasses those arrays that can result by specifying element-type as the element type to the function make-array. Under this interpretation (array character) might be the same type as (array t) (although it also might not be the same). See upgraded-array-element-type. However,
is still not a legitimate test of whether the array foo can hold a character; one must still say
to determine that question.
As a general rule, a compiler would be justified in transforming
into
It may also make inferences involving more complex functions, such as position or find. For example, find applied to an array always returns either nil or an object whose type is the element type of the array.
Type string is the union of one or more specialized vector types, the types of whose elements are subtypes of the type character.
X3J13 voted in January 1989 to change typep and subtypep so that the specialized complex type specifier means the same thing for discrimination purposes as for declaration purposes. See upgraded-complex-part-type.
The arg-type that follows a &rest marker indicates the type of each actual argument that would be gathered into the list for a &rest parameter, and not the type of the &rest parameter itself (which is always list). Thus one might declare the function gcd to be of type (function (&rest integer) integer), or the function aref to be of type (function (array &rest fixnum) t).
A declaration specifier of the form
implies that any function call of the form
within the scope of the declaration can be treated as if it were rewritten to use the-forms in the following manner:
That is, it is an error for any of the actual arguments not to be of its specified type arg-type or for the result not to be of the specified type value-type. (In particular, if any argument is not of its specified type, then the result is not guaranteed to be of the specified type—if indeed a result is returned at all.)
Similarly, a declaration specifier of the form
is interpreted to mean that any reference to the variable var will find that its value is a function, and that it is an error to call this function with any actual argument not of its specified type arg-type. Also, it is an error for the result not to be of the specified type value-type. For example, a function call of the form
could be rewritten to use the-forms as well. If any argument is not of its specified type, then the result is not guaranteed to be of the specified type—if indeed a result is returned at all.
Thus, a type or ftype declaration specifier describes type requirements imposed on calls to a function as opposed to requirements imposed on the definition of the function. This is analogous to the treatment of type declarations of variables as imposing type requirements on references to variables, rather than on the contents of variables. See the vote of X3J13 on type declaration specifiers in general, discussed in section 9.2.
In the same manner as for variable type declarations in general, if two or more of these declarations apply to the same function call (which can occur if declaration scopes are suitably nested), then they all apply; in effect, the types for each argument or result are intersected. For example, the code fragment
may be regarded as equivalent to
or to
That is, sam had better be both featherless and a biped, and the result of butcher-fudge had better be both opposable and a digit; otherwise the code is in error. Therefore a compiler may generate code that relies on these type assumptions, for example.