Function type-of

Syntax:

Arguments and Values:

object—an object.

typespec—a type specifier.

Description:

Returns a type specifier, typespec, for a type that has the object as an element. The typespec satisfies the following:

• 1. For any object that is an element of some built-in type:
  • a. the type returned is a recognizable subtype of that built-in type.

  • b. KMP: I added MEMBER and EQL because they seemed to be missing only by accident. The discussion of TYPE-OF-UNDERCONSTRAINED seems to imply that MEMBER is missing due to editing error. And I think EQL was added later. -kmp 3-Jun-91the type returned does not involve and, eql, member, not, or, satisfies, or values.

• 2. For all objects, (typep object (type-of object)) returns true. Per Barmar:Implicit in this is that type specifiers which are not valid for use with typep, such as the list form of the function type specifier, are never returned by type-of.

• 3. The type returned by type-of is always a recognizable subtype of the class returned by class-of. That is,

   (subtypep (type-of object) (class-of object)) → true, true
  

• 4. For objects of metaclass structure-class or standard-class, and for conditions, type-of returns the proper name of the class returned by class-of if it has a proper name, and otherwise returns the class itself. In particular, for objects created by the constructor function of a structure defined with defstruct without a :type option, type-of returns the structure name; and for objects created by make-condition, the typespec is the name of the condition type.

• 5. For each of the types short-float, single-float, double-float, or long-float of which the object is an element, the typespec is a recognizable subtype of that type.

(The CLOS specification has already specified that class objects are acceptable wherever \term{type specifiers} are, and in particular, as input to SUBTYPEP and TYPEP.) This proposal is intended to be consistent with 88-002R, and not to conflict with any of the definitions in that document.

If \param{object} is not a user-defined named \term{structure} created by \macref{defstruct}, \funref{type-of} returns a \term{type} of which \param{object} is a member. 4.9.0 3 The result in this case is \term{implementation-dependent}. For example: \code (type-of "abc") \EV SIMPLE-STRING (type-of "abc") \EV STRING (type-of "abc") \EV ARRAY \endcode If \param{object} is a user-defined named \term{structure} created by \macref{defstruct}, then \funref{type-of} returns the type name of that \term{structure}.

Examples:

 (type-of 'a) → SYMBOL          
 (type-of '(1 . 2))
→ CONS
OR→ (CONS FIXNUM FIXNUM)
 (type-of #c(0 1))
→ COMPLEX
OR→ (COMPLEX INTEGER)
 (defstruct temp-struct x y z) → TEMP-STRUCT
 (type-of (make-temp-struct)) → TEMP-STRUCT
 (type-of "abc")
→ STRING
OR→ (STRING 3)
 (subtypep (type-of "abc") 'string) → true, true
 (type-of (expt 2 40))
→ BIGNUM
OR→ INTEGER
OR→ (INTEGER 1099511627776 1099511627776)
OR→ SYSTEM::TWO-WORD-BIGNUM
OR→ FIXNUM
 (subtypep (type-of 112312) 'integer) → true, true
 (defvar *foo* (make-array 5 :element-type t)) → *FOO*
 (class-name (class-of *foo*)) → VECTOR
 (type-of *foo*)
→ VECTOR
OR→ (VECTOR T 5)

Affected By:

None.

Exceptional Situations:

None.

See Also:

array-element-type, class-of, defstruct, typecase, typep, Section 4.2 (Types)

Notes:

Implementors are encouraged to arrange for type-of to return the most specific \term{type} that can be conveniently computed and is likely to be useful to the user.a portable value. Barmar: "a type specifier defined in this standard" KMP: This is a little messy. The problem is that user-defined types are not directly described here,...