Quirks of Common Lisp Types

While the post references a link to the 'Type Hierarchy of Strings'[0], here is the full type tree[1] for Common Lisp.

[0]: https://lispcookbook.github.io/cl-cookbook/strings.html#stri...

[1]: https://sellout.github.io/2012/03/03/common-lisp-type-hierar...

I think this article over-sells (to a point of being misleading) the amount of static type checking offered in Common Lisp even by a relatively good implementation like SBCL.

SBCL's static type checking provides in practice virtually zero guarantees about whether compiling your code actually implies the inexistence of type errors. In that regard, I like to consider SBCL's static type errors to be a mere courtesy [1].

Typically, the static type errors TFA demonstrates are nullified as soon as anything is abstracted away into a function. To show a trivial example:

    (+ 2 "2")

    (defun id (x) x)

    (+ 2 (id "2"))

    id :: a -> a
    id x = x

    template <typename A>
    A id(A x) {
        return x;
    }

    (declaim (ftype (function (string) string) id))

    (declaim (ftype (function (t) t) id))

[1] SBCL and CMUCL aren't totally random in what static type checking they perform, and the programmer can absolutely make profitable use of this checking, but you have to be quite knowledgeable of the implementation to know what exactly you can rely on.

> Note also that this isn't a linear hierarchy: in the String example above, simple-array and string are unrelated.

Are you sure? If that's the case, it would have to be that the object is not a suitable argument to a method parameter of type string.

Don't guess about whether they're considered unrelated in that implementation, use subtypep and typep.

If (typep "X" 'string) yields true, then the type of "X", whatever it is, is related to string.

Since the title includes the word "quirks," the observation I'll make here is entirely appropriate: the post oversimplifies this.

It says: "So as we can see, at both run-time and compile-time, Common Lisp does typechecking to prevent silly errors."

This is not entirely accurate, as the Common Lisp standard does not require such typechecking.

The Common Lisp standard specifies the types of the arguments that a function expects. It generally does not specify what happens if the function receives arguments of unexpected types. It explicitly does not specify this: the standard says that if you give a function unexpected types, the consequences are undefined:

https://www.lispworks.com/documentation/HyperSpec/Body/01_dd...

where "undefined" means that any behavior, from an error message to a harmless failure to a catastrophic failure, can occur:

https://www.lispworks.com/documentation/HyperSpec/Body/01_db...

Let's take + (the addition function) as an example. It "might signal" a type error if some argument is not a number:

https://www.lispworks.com/documentation/HyperSpec/Body/f_pl....

where "might signal" means that the result is unpredictable but if the function does signal an error, it will be of the given type:

https://www.lispworks.com/documentation/HyperSpec/Body/01_db...

I can understand why the standard is written this way. Checking the types of arguments takes time. Sometimes you might not want to check the types for performance reasons.

It seems the author is using SBCL. As a practical matter, SBCL on the default settings will check the types of arguments. SBCL's manual (along with the manual of its predecessor, CMUCL) discusses how to manipulate these settings - the author discusses this, with the DECLARE form. But Common Lisp does not require this checking, so if you need your types checked, consult your implementation's manual. Indeed, SBCL allows you to change the settings for SPEED and SAFETY to specify how much type-checking you want.

All these caveats are also true for structures. The author says structure types are checked - again, as a practical matter, SBCL will check these unless you tell it not to. But that's not what the standard requires. Indeed, the standard explicitly states that "It is implementation-dependent whether the type is checked when initializing a slot or when assigning to it."

https://www.lispworks.com/documentation/HyperSpec/Body/m_def...

[edit] Relevant part of SBCL manual is here:

https://www.sbcl.org/manual/#Declarations-as-Assertions

The type hierarchy in the standard has an amusing quirk.

Arrays can have an element type specified, and this type is "upgraded" to a type that is actually store in the array. This upgraded type is a supertype of the actual element type. Upgrading must also preserve subtypes: if T1 is a subtype of T2, then upgrade(T1) must be a subtype of upgrade(T2) (not necessarily a proper subtype, even if T1 != T2).

Now, the standard requires that the upgrade of BIT is BIT (that is, (INTEGER 0 1)), and the upgrade of CHARACTER is CHARACTER. So, what is the upgrade of NIL, the empty type? It must be a subtype of both BIT and CHARACTER, but the only type with that property is NIL itself.

So, the standard requires there must be a specialized array type with element type NIL. That is, it cannot store any values at all.

This reminds me of my favorite special form in common-lisp: `the`. https://www.lispworks.com/documentation/HyperSpec/Body/s_the...

(the fixnum (compute-my-fixnum-value))

This specifies that the value in the form in the second argument is of the type specified by the first argument. One might assume that this is what other languages call `assert`, and it can be; your compiler / interpreter can be configured to assert if it detects a mismatch between the two.

... but the spec actually specifies that if they don't match, the behavior is undefined. `the` is also an opportunity for the compiler to throw away some dynamic typechecking logic; essentially, it's a chance to paint racing stripes on the implementation so it goes faster at the cost of risking undefined behavior.