3 ms·
Prelude> head [] * Exception: Prelude.head: empty list Damn I think might need to trace this one.
by evilthinker 16y ago
Prelude> head []
* Exception: Prelude.head: empty list
Damn I think might need to trace this one.
- nickik 16y agoI thought that this was implemented. I Clojure its like this: (first []) --> nil What is in that list? Answer nothing. I think thats a way to go too.
- frio 16y agoI haven't used Clojure, so excuse me if there's something I'm missing here, but doesn't that mean that the following is true? first [nil] == first [] In which case, I prefer the Haskell way, as it's more specific.
- pufuwozu 16y agouser=> (= (first [nil]) (first [])) true
- stusmith1977 16y agoI strongly disagree. If you're expecting the first value of a list, what use is nil? If 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) = ...
- nickik 16y agoWhy would you have nil in a list of integers? In cases where you encounter nil instead of some type you look for you can add behavior to nil without doing if nil? in the function all the time. 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)?