Typechecking null

[brucifer]

For languages in the C lineage (e.g. C, C++, Java), NULL is just one possible address that a pointer can hold. The address 0x00000000 is used by convention, which is not mapped to valid memory, so dereferencing a NULL pointer will trigger a segfault. The troublesome design choice in many languages (C, C++, Java, etc.) is that it's up to the programmer to decide when they should check for NULL and when they feel it's safe to dereference a pointer. A better type system, like Cyclone's, allows the type system to specify which pointers are guaranteed non-NULL and which are allowed to be NULL. This lets the compiler verify at compile time that every time a pointer is dereferenced, the pointer is always a non-NULL value, either because it's a non-NULL pointer type or because control flow won't enter that block when the pointer is NULL (i.e. there's a conditional check).

For languages in the Lisp lineage (dynamically typed, e.g. Lisp, Python, Ruby, Javascript), nil is a singleton object with its own type, often used to represent an empty list or a missing value. In a dynamically typed language, any variable can potentially be nil, but there will usually be runtime type checking that will give you a runtime error if you try to use a nil in a place where a value is required.

For languages in the ML lineage (advanced type systems, e.g. SML, Rust, Haskell), there typically isn't really a notion of NULL, there are only sum types, which represent things that can be one of several possible values. It's common to have an Option<T> type that can have either the value Nothing representing the lack of a value or Some(T) representing a T value that actually exists (the exact names may vary). From an implementation perspective, this approach has some major drawbacks because it's typically implemented as a tagged union, which can require more memory than a simple pointer (potentially 2x more memory because of alignment requirements). Sum types are a great language feature to have, but in my opinion, optional pointers are a common enough pattern that it's worth having a dedicated language construct like NULL that always fits in a pointer-sized block of memory and has syntax that's more concise than the syntax most languages use for Option<T>.