Exactly. The primary purpose of type declarations in Common Lisp is to give the compiler a hint that you are taking responsibility for type management so the machine code doesn't need to check the type at runtime. But the spec does not require that the compiler obey that hint, and if the compiler does obey the hint the spec says it's not the compiler's fault if you screw up the type that you took responsibility for.
An additional purpose for type declarations is not mentioned in the spec: Static analysis. SBCL goes the extra mile and does do some static analysis with your type declarations, which means it catches many kinds of programmer errors at compile time. Not all CL implementations do this.
If you want a Common Lisp that performs thorough static analysis, use Coalton.
This is one of the things I appreciate about Common LISP's approach: it allows for undefined behavior, but UB is (mostly, as far as I know, I'm sure someone will jump in and correct me ;) ) off by default.
And I think that's the right place for the default to be. C and C++ support UB as well and there are definitely times where you want that for the speed benefits it affords the compiler's output, but getting to UB in those languages is as easy as creating a character array and then copying a string that is too long into that character array (gcc will warn you, but about the conversion of a string literal into a char pointer, not about the buffer overrun).
And with the C++ spec having a page count exceeding the entire Lord of the Rings trilogy, that's a lot of language definition for undefined behavior to live in.
> it allows for undefined behavior, but UB is (mostly, as far as I know, I'm sure someone will jump in and correct me ;) ) off by default.
It's actually much more sophisticated than that. See:
https://www.lispworks.com/documentation/HyperSpec/Body/01_db...
would you happen to know whether the spec requires a default value for the safety optimization quality, when no declartions are given in the program? Or is it implementation-defined; could conforming implementations be unsafe by default.
No idea, sorry.
[UPDATE] There is a clue in section 3.3.1 Minimal Declaration Processing Requirements:
"A safety declaration that increases the current safety level must always be recognized. An implementation that always processes code as if safety were high may safely ignore this declaration."
To me this seems to imply that the default value of SAFETY is implementation-dependent.
I also found that passage. It's either implementation-defined or else they went incredibly out of their way to hide the requirements.