>For example, it cannot specialize an element type for lists. Yes, but that would be a CL violation (or an extension to provide via something else than DEFTYPE

>For example, it cannot specialize an element type for lists. Yes, but that would be a CL violation (or an extension to provide via something else than DEFTYPE), since DEFTYPE's body can't be infinitely recursive; cf https://www.lispworks.com/documentation/HyperSpec/Body/m_deftp.htm https://www.lispworks.com/documentation/HyperSpec/Body/m_def... >if you attempt to (declaim) every function, you will immediately see how vague and insufficient the types come out compared to even Python. Indeed, but 1) it is used by the compiler itself while cpython currently ignores annotations and 2) runtime and buildtime typing use the same semantics and syntax, so you don't need band-aids like https://github.com/agronholm/typeguard https://github.com/agronholm/typeguard But yeah, CL's type system is lacking in many places. In order of practical advantages and difficulty to add (maybe): recursive DEFTYPE, typed HASH-TABLEs (I mean the keys and values), static typing of CLOS slots (invasive, like https://github.com/marcoheisig/fast-generic-functions https://github.com/marcoheisig/fast-generic-functions), ..., parametric typing beyond ARRAYs.