Prelude> head []
* Exception: Prelude.head: empty list
Damn I think might need to trace this one.
Damn I think might need to trace this one.
I Clojure its like this: (first []) --> nil
What is in that list? Answer nothing.
I think thats a way to go too.
first [nil] == first []
user=> (= (first [nil]) (first []))
trueIf you have a list of Ints, then what can you do with nil returned? It's not an Int.
Nils have a habit of propagating through the whole type system, and you then need to have rules about how they apply to every function. (What is 1+nil? What is nil:[1,2,3]?).
Eventually every single function will either have odd behaviour when confronted with a nil, or will be a source of exceptions (which are generally undesirable in a pure functional setting).
Haskell encourages you to write patterns that check for these edge cases, and handle them explicitly:
foo [] = ...
foo (x:xs) = ...
I would agree that not having nil is better if you have these big typesystems but for a dynamic languge its hard to avoid.
Question: Don't these static langauge use "unit" to signal what nil would do in clojure (in some casses)?