title: Why does Haskell's `head` crash on an empty list (or why *doesn't* it return an empty list)? (Language philosophy)
body: <p>Note to other potential contributors: Please don't hesitate to use abstract or mathematical notations to make your point. If I find your answer unclear, I will ask for elucidation, but otherwise feel free to express yourself in a comfortable fashion.</p>
  
  <p>To be clear: I am <em>not</em> looking for a "safe" <code>head</code>, nor is the choice of <code>head</code> in particular exceptionally meaningful. The meat of the question follows the discussion of <code>head</code> and <code>head'</code>, which serve to provide context.</p>
  
  <p>I've been hacking away with Haskell for a few months now (to the point that it has become my main language), but I am admittedly not well-informed about some of the more advanced concepts nor the details of the language's philosophy (though I am more than willing to learn). My question then is not so much a technical one (unless it is and I just don't realize it) as it is one of philosophy.</p>
  
  <p>For this example, I am speaking of <code>head</code>.</p>
  
  <p>As I imagine you'll know,</p>
  
  <pre><code>Prelude&gt; head []    
  *** Exception: Prelude.head: empty list
  </code></pre>
  
  <p>This follows from <code>head :: [a] -&gt; a</code>. Fair enough. Obviously one cannot return an element of (hand-wavingly) no type. But at the same time, it is simple (if not trivial) to define </p>
  
  <pre><code>head' :: [a] -&gt; Maybe a
  head' []     = Nothing
  head' (x:xs) = Just x
  </code></pre>
  
  <p>I've seen some little discussion of this <a href="http://book.realworldhaskell.org/read/functional-programming.html">here</a> in the comment section of certain statements. Notably, one Alex Stangl says </p>
  
  <blockquote>
    <p>'There are good reasons not to make everything "safe" and to throw exceptions when preconditions are violated.'</p>
  </blockquote>
  
  <p>I do not necessarily question this assertion, but I am curious as to what these "good reasons" are.</p>
  
  <p>Additionally, a Paul Johnson says, </p>
  
  <blockquote>
    <p>'For instance you could define "safeHead :: [a] -> Maybe a", but now instead of either handling an empty list or proving it can't happen, you have to handle "Nothing" or prove it can't happen.'</p>
  </blockquote>
  
  <p>The tone that I read from that comment suggests that this is a notable increase in difficulty/complexity/something, but I am not sure that I grasp what he's putting out there.</p>
  
  <p>One Steven Pruzina says (in 2011, no less), </p>
  
  <blockquote>
    <p>"There's a deeper reason why e.g 'head' can't be crash-proof. To be polymorphic yet handle an empty list, 'head' must always return a variable of the type which is absent from any particular empty list. It would be Delphic if Haskell could do that...".</p>
  </blockquote>
  
  <p>Is polymorphism lost by allowing empty list handling? If so, how so, and why? Are there particular cases which would make this obvious? <strong>This section amply answered by @Russell O'Connor.</strong> Any further thoughts are, of course, appreciated.</p>
  
  <p>I'll edit this as clarity and suggestion dictates. Any thoughts, papers, etc., you can provide will be most appreciated.</p>