CL-USER> (setf universe (find-class 't)) #<BUILT-IN-CLASS T> CL-USER> (typep universe universe) T
CL-USER> (setf universe (find-class 't))
CL-USER> (typep universe universe)
I’m not arguing against type theories, not arguing against the usefulness of various forms of type inference, not arguing against reasonable requests, not arguing against the desire to reason about code, not arguing against tools to ensure correctness and all that good stuff.
I am arguing against the belief that types belong in the compiler and not in the running system, and I am arguing that the specific idea of a “parameterized type” is moot in Common Lisp, both because we have typed objects and because we have a type hierarchy for all types with specialization on disjoint types.
I am arguing that parameterized types are necessary when you accept disjoint types and believe in the compiler as your only savior.
Is a sortable array an array that sorts or a sorter represented by an array? If you believe that types address all design issues you must make that decision.
Every language has a type system; a particular way of organizing nouns into types, ﬁguring out which verbs make sense on which types, and relating types to one another.
Some languages are strict, and others more relaxed. Some emphasize hierarchy, and others a more ad-hoc view of the world.
Making that happen in a language design should involve some subtle shifts in the way data is conceptualized. That isn’t a digression in a discussion of types, because the way we conceptualize data has deep, not to say insidious, effects on the nature of typing.
As for the types themselves, I suggest we abandon the whole notion of types in favor of a lightweight mathematical notion of sets — and avoid using the word “type” as it naturally drags us back toward the conceptual morass of type theory that we need to escape.