The decisions the Elm team make continue to impress me. I like that they are willing to break from tradition in order to create a better programming environment. In particular, changing the head function to be total is a great move.
head : List a -> Maybe a
Compare that with the same function in Haskell.
head :: [a] -> a
To me, the Elm version makes more sense. (It also avoids having to explain that "[a]" means "list of 'a's".)
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.
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)
Release of new version of Elm (A functional reactive language for interactive applications)
"This release introduces tasks, a way to define complex asynchronous operations. Similar to C#’s tasks and JavaScript’s promises, tasks make it simple to describe long-running effects and keep things responsive. They also provide a way to wrap up tons of browser APIs in Elm."
This is awesome. Dealing with HTTP requests used to be a pain since they were all signals even when they were used only once, which was not intuitive. This should make the language much more usable.
Congratulations to the Elm team!
As a side note scala-js provides an interesting alternative.
In the new Principles of Reactive Programming, https://class.coursera.org/reactive-002/assignment, a decent RFP example using scalajs was given.
[+] [-] taylorfausak|11 years ago|reply
[+] [-] lisperforlife|11 years ago|reply
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.
[+] [-] munro|11 years ago|reply
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. :)
[+] [-] pka|11 years ago|reply
[+] [-] thomasweiser|11 years ago|reply
"This release introduces tasks, a way to define complex asynchronous operations. Similar to C#’s tasks and JavaScript’s promises, tasks make it simple to describe long-running effects and keep things responsive. They also provide a way to wrap up tons of browser APIs in Elm."
[+] [-] rudi-c|11 years ago|reply
[+] [-] CMCDragonkai|11 years ago|reply
[+] [-] kailuowang|11 years ago|reply
[+] [-] habitue|11 years ago|reply
[+] [-] toomim|11 years ago|reply
It seems like lots of people in the functional community are fans.
I spent some time trying to get it, and I got part of it, but I'm not yet a fan.
[+] [-] moomin|11 years ago|reply
[+] [-] ams6110|11 years ago|reply