undefined | Better HN

0 pointsjunke8y ago0 comments

It goes like this: the claim is that dynamically typed "don't count for the comparison" because "compile time type checks are impossible". Even if we suppose that nil values or union types are useless at runtime (they aren't), it is not true that dynamically typed languages could not be analyzed statically. Not only compile time type checks are possible, they are sometimes expected to happen and already part of some language's design.

Python added type hints recently, but in Common Lisp, there is not only a null type (which contains the nil value), but also an empty type: there is no practical use in defining a type for which there is no possible value at runtime, except if the language and its type system are designed to support static analysis. It it expected that a compiler can optimize away things that are known in advance to be impossible, or help you detect errors statically.

0 comments

kazinator8y ago

(And that empty type is the one named by the symbol nil.)

The nil type is useful at run-time because it constitutes the bottom of the type spindle: just like in set theory the empty set is a subset of every set, including itself, the type nil is a subtype of every type, including itself.

This can be used at run-time; e.g. (subtypep nil 'integer) -> t.

We can't just exclude this value from the type domain on the grounds that it's static only. "Sorry, you don't get a bottom plug on your type spindle at run time ...". :)

j / k navigate · click thread line to collapse

0 pointsjunke8y ago0 comments

0 comments

kazinator8y ago

(And that empty type is the one named by the symbol nil.)

This can be used at run-time; e.g. (subtypep nil 'integer) -> t.

We can't just exclude this value from the type domain on the grounds that it's static only. "Sorry, you don't get a bottom plug on your type spindle at run time ...". :)

j / k navigate · click thread line to collapse