5 ms·

There have been numerous attempts at making a better Haskell prelude. Basically basic functions like getting the head of a list can have a runtime error (for ex

There have been numerous attempts at making a better Haskell prelude. Basically basic functions like getting the head of a list can have a runtime error (for example, the list is empty). That's unnecessary in Haskell (could return a `Maybe a`). Stephen Diehl is the guy to do this right. I've been incredulous of other replacement preludes in the past but I may use this one.

baldfat 11y ago
I have found Haskell just has so many of these "paper cuts" that I have just walked away.
- kccqzy 11y ago
  That's really a sad thing to hear, because for the experienced the benefits brought about by Haskell is so plainly obvious that it's obviously worth the trouble to navigate the mine of the Prelude full of legacy cruft.
  - baldfat 11y ago
    My #1 issue was I work at several sites and at home. I don't really use a laptop so I just use git as a single user. The package management was such that I could never have the same environment in multiple of locations. Something would break and I spent more time fixing then doing.
    - mcbuilder 11y ago
      That was a problem commonly called 'cabal hell'. You can alternatively use the stack build tool, https://github.com/commercialhaskell/stack https://github.com/commercialhaskell/stack, which works by fixing package versions against stackage snapshots. Before using stack I was always afraid to come back to a Haskell project after a few months, since using stack that's not a problem. Also, you don't have to worry about different machines, because stack is ensuring that you have the pretty much same build environment (at least the Haskell packages will have the exact same version). Stack also recently added support for using Nix to solve the problem fixing non-Haskell dependencies for a project.
      - baldfat 11y ago
        Well after the love affair I have with Racket wears off I just might try to start back up in Haskell. Thanks! Love the idea of using nix.
      - rspeer 11y ago
        This looks so much better than Cabal. Why have I never heard about it in all the guides and StackOverflow answers I've had to search through when trying to escape Cabal hell?
        koloron 11y ago
        The project has existed only since last summer.
    - koloron 11y ago
      mcbuilder has already mentioned it, but I really want to emphasize that dependency management in Haskell is an entirely different story now with stack.
- girvo 11y ago
  I agree, but I've fallen in love with Purescript[0] recently instead, and its made it easier to ease into Haskell. Although to be honest, I prefer Purescript as a language! [0] http://www.purescript.org/ http://www.purescript.org/
  - nv-vn 11y ago
    I could see that. I find that Haskell specifically is very hard to ease into, whereas a lot of similar languages are much easier. For me, I wasn't comfortable with my Haskell skills until I learned Idris, which is arguably a more difficult language -- ironically, I found the Idris documentation to be a lot more user friendly than Haskell's just because it comes from the official team (and I'm sure that Purescript is like this too). For anyone struggling to learn Haskell, I'd probably recommend a different purely functional language first (at least until haskellbook comes out).
  - kyllo 11y ago
    That's because PureScript is what Haskell would be if it were written in the last 2-3 years starting from a clean slate. It doesn't have to deal with legacy code.
runchberries 11y ago
To my understanding Haskell prelude is unsafe because Haskell sometime sacrifices usability/friendliness for satisfying certain theorems. http://stackoverflow.com/questions/6364409/why-does-haskells-head-crash-on-an-empty-list-or-why-doesnt-it-return-an http://stackoverflow.com/questions/6364409/why-does-haskells...
- drostie 11y ago
  Partly. Tsuyoshi Ito's answer on that page is IMO better than the original: `head` mattered at a time when pattern matching didn't exist; but today the only reason to use `head` is to form some sort of pointfree expression operating on lists that you've already filtered to be not-null. That is, you're doing `map (transform . head) . takeWhile (not . null)` or something, or maybe `takeWhile` is replaced with `filter` or so. If you cannot assert that the list is non-null then you have to handle two branches, and this code will generally look clearer if you pull it into a `where` clause and write it with pattern matching rather than with an adjusted `head` followed immediately by an appropriate `maybe` function.
  - marchelzo 11y ago
    With `[a] -> Maybe a`, it's not so bad if you use `catMaybes` from Data.Maybe. map transform . catMaybes . map safeHead
    - koloron 11y ago
      Even better with mapMaybe: map transform . mapMaybe safeHead
- T-R 11y ago
  Satisfying theorems is generally for the purpose of friendliness, by ensuring consistency. In this case, they had two options: (a) be consistent as if the language had type-level literals, which resulted in nicer code in the usual case, but some unsafety on unchecked edge cases, or (b) give more safety, but force everyone to check for the empty list even when they don't need to. They went with (a) - it's the type of decision Haskell is (I'd argue incorrectly) criticized for not doing - people complain about having to prove things to their compiler. Of course, in hindsight, and given the language ecosystem now (and that option (b) is instead consistent with all the monad-centric libraries, etc.), (b) seems like a better choice. Which one is better could just as easily change again if empty lists became distinguished at the type-level in Prelude in the future. This is also something that would either crash, or be similarly inconsistent (just return null, causing eventual crashes instead) in any other language. It's notable, though, that the community is making effort to fix these tiny inconsistencies, rather than punting on it for backwards compatibility, as so many other ecosystems do.
Kenji 11y ago
Exactly. Many people do not know how hard it is to improve on the current prelude, even though it's entirely possible. Most decisions and tradeoffs in Haskell weren't just done on a whim, there is an ideology and reasoning behind it (I am not sure if I want a maybe monad as a possible result of my list operations, though). My first thought when I read that headline was "Wow, good luck with that." I do not know Stephen Diehl but I hope you're right about his capabilities, it would definitely be exciting to see that in Haskell!

baldfat 11y ago

I have found Haskell just has so many of these "paper cuts" that I have just walked away.

kccqzy 11y ago
That's really a sad thing to hear, because for the experienced the benefits brought about by Haskell is so plainly obvious that it's obviously worth the trouble to navigate the mine of the Prelude full of legacy cruft.
- baldfat 11y ago
  My #1 issue was I work at several sites and at home. I don't really use a laptop so I just use git as a single user. The package management was such that I could never have the same environment in multiple of locations. Something would break and I spent more time fixing then doing.
  - mcbuilder 11y ago
    That was a problem commonly called 'cabal hell'. You can alternatively use the stack build tool, https://github.com/commercialhaskell/stack https://github.com/commercialhaskell/stack, which works by fixing package versions against stackage snapshots. Before using stack I was always afraid to come back to a Haskell project after a few months, since using stack that's not a problem. Also, you don't have to worry about different machines, because stack is ensuring that you have the pretty much same build environment (at least the Haskell packages will have the exact same version). Stack also recently added support for using Nix to solve the problem fixing non-Haskell dependencies for a project.
    - baldfat 11y ago
      Well after the love affair I have with Racket wears off I just might try to start back up in Haskell. Thanks! Love the idea of using nix.
    - rspeer 11y ago
      This looks so much better than Cabal. Why have I never heard about it in all the guides and StackOverflow answers I've had to search through when trying to escape Cabal hell?
      - koloron 11y ago
        The project has existed only since last summer.
  - koloron 11y ago
    mcbuilder has already mentioned it, but I really want to emphasize that dependency management in Haskell is an entirely different story now with stack.
girvo 11y ago
I agree, but I've fallen in love with Purescript[0] recently instead, and its made it easier to ease into Haskell. Although to be honest, I prefer Purescript as a language! [0] http://www.purescript.org/ http://www.purescript.org/
- nv-vn 11y ago
  I could see that. I find that Haskell specifically is very hard to ease into, whereas a lot of similar languages are much easier. For me, I wasn't comfortable with my Haskell skills until I learned Idris, which is arguably a more difficult language -- ironically, I found the Idris documentation to be a lot more user friendly than Haskell's just because it comes from the official team (and I'm sure that Purescript is like this too). For anyone struggling to learn Haskell, I'd probably recommend a different purely functional language first (at least until haskellbook comes out).
- kyllo 11y ago
  That's because PureScript is what Haskell would be if it were written in the last 2-3 years starting from a clean slate. It doesn't have to deal with legacy code.

runchberries 11y ago

To my understanding Haskell prelude is unsafe because Haskell sometime sacrifices usability/friendliness for satisfying certain theorems. http://stackoverflow.com/questions/6364409/why-does-haskells-head-crash-on-an-empty-list-or-why-doesnt-it-return-an http://stackoverflow.com/questions/6364409/why-does-haskells...

drostie 11y ago
Partly. Tsuyoshi Ito's answer on that page is IMO better than the original: `head` mattered at a time when pattern matching didn't exist; but today the only reason to use `head` is to form some sort of pointfree expression operating on lists that you've already filtered to be not-null. That is, you're doing `map (transform . head) . takeWhile (not . null)` or something, or maybe `takeWhile` is replaced with `filter` or so. If you cannot assert that the list is non-null then you have to handle two branches, and this code will generally look clearer if you pull it into a `where` clause and write it with pattern matching rather than with an adjusted `head` followed immediately by an appropriate `maybe` function.
- marchelzo 11y ago
  With `[a] -> Maybe a`, it's not so bad if you use `catMaybes` from Data.Maybe. map transform . catMaybes . map safeHead
  - koloron 11y ago
    Even better with mapMaybe: map transform . mapMaybe safeHead
T-R 11y ago
Satisfying theorems is generally for the purpose of friendliness, by ensuring consistency. In this case, they had two options: (a) be consistent as if the language had type-level literals, which resulted in nicer code in the usual case, but some unsafety on unchecked edge cases, or (b) give more safety, but force everyone to check for the empty list even when they don't need to. They went with (a) - it's the type of decision Haskell is (I'd argue incorrectly) criticized for not doing - people complain about having to prove things to their compiler. Of course, in hindsight, and given the language ecosystem now (and that option (b) is instead consistent with all the monad-centric libraries, etc.), (b) seems like a better choice. Which one is better could just as easily change again if empty lists became distinguished at the type-level in Prelude in the future. This is also something that would either crash, or be similarly inconsistent (just return null, causing eventual crashes instead) in any other language. It's notable, though, that the community is making effort to fix these tiny inconsistencies, rather than punting on it for backwards compatibility, as so many other ecosystems do.

Kenji 11y ago

Exactly. Many people do not know how hard it is to improve on the current prelude, even though it's entirely possible. Most decisions and tradeoffs in Haskell weren't just done on a whim, there is an ideology and reasoning behind it (I am not sure if I want a maybe monad as a possible result of my list operations, though). My first thought when I read that headline was "Wow, good luck with that." I do not know Stephen Diehl but I hope you're right about his capabilities, it would definitely be exciting to see that in Haskell!