In addition to the lexical change, the result now returns a Maybe instead of the actual element. This was done to avoid runtime crashes when head encounters an empty list. However, this means that everytime you have to use head, you will have to pattern match on Just x/Nothing to consume it. However, you can still use the (x::xs) pattern matching syntax to obtain head and tail and pattern match on [] for empty lists.

Absence of applicatives or monads mean that you have to explicitly pattern match on Just/Nothing everytime. There is a proposal to add `?` as an operator to obtain the head of the list without the Maybe and provide a default value if it is Nothing. Also there is another proposal to allow `unsafe` for the program to crash if the result is Nothing.

> Absence of applicatives or monads mean that you have to explicitly pattern match on Just/Nothing everytime.

It seems to me that most real uses can probably be solved by map, and withDefault if you really need to get out of the Maybe monad for some reason (though map should make it so that you don't have to for most things.)

> There is a proposal to add `?` as an operator to obtain the head of the list without the Maybe and provide a default value if it is Nothing.

Since elm supports user-defined operators, can't you just do that yourself. Something like:

  list ? default = withDefault default (head list)

Yep! The proposal is to add that to the core libraries, and is basically just waiting to see how much people actually want to use withDefault that way in practice.

There's already withDefault to make that concise, so you can do things like this:

  withDefault 0 (head listOfNumbers)

No need to pattern match every time. :)

Docs for withDefault: http://package.elm-lang.org/packages/elm-lang/core/1.0.0/May...

I've defined (?) in http://package.elm-lang.org/packages/circuithub/elm-maybe-ex... in the mean time.

head and (!!) have been a source of off by one errors for me. I've yet to learn Idris, but I have the hope that dependent types may save me from off by one errors. Sometimes you always want head to return something, so it would be nice to find those logic errors statically.

In this case, I definitely prefer the correct version Elm implements. I think Haskell just doesn't want to admit it's type system can't model everything. :)

It would probably help to also have something like this:

  singleton : a -> NonEmpty a
  cons : a -> NonEmpty a -> NonEmpty a
  head : NonEmpty a -> a
  last : NonEmpty a -> a
  init : NonEmpty a -> Maybe (NonEmpty a)
  tail : NonEmpty a -> Maybe (NonEmpty a)