3 ms·

Haskell desperately needs a thorough revamping of its Prelude, and it really has to become part of an updated language standard document. Too much of the burde

Haskell desperately needs a thorough revamping of its Prelude, and it really has to become part of an updated language standard document. Too much of the burden of learning Haskell consists of figuring out how to dodge the pitfalls in the current Prelude. The arguments against revamping basically boil down to "but that would obsolete this old textbook!" and that just doesn't wash. Getting this job done right is essential to Haskell becoming a "hundred-year language".

pklausler 11y ago
Some specific things that I do in Haskell programs written for production: 1. Define a FutureProofing.hs module that anticipates changes to GHC that are, or now were, inevitable, such as Monad becoming a subclass of Applicative, and "fail" moving out of Monad. I redefine MonadIO to depend on Applicative so that I can use "pure" universally, hiding "return" from Prelude. 2. I have a longish list of things I hide from the Prelude, besides "return" (above). I haven't yet crossed the Rubicon of inhibiting the standard Prelude altogether, but I don't allow myself to use the bad parts. 3. I have a GenericIO.hs module that defines a typeclass that allows me to use any type of string for pathnames or data. This eliminates nearly all boilerplate conversions when dealing with the IO library and anticipates the changes that might eventually come to the standard Prelude. In short, I expect and anticipate the standard library to improve, and will not have to do much work to exploit those improvements when they do arrive. I steer clear of the pitfalls. And unlike the OP, I try to avoid complicating the problem by adding new things to my universal imports; I don't mind having longish import lists at the heads of my modules (and I always enumerate all the names that I import).
- koloron 11y ago
  If you're still using string types for pathnames you may want to check out the path and path-io packages. The path package defines a Path type parameterized by its locality (absolute or relative) and type (pointing at a file or a directory). Especially the distinction between relative and absolute paths adds a nice safety layer.
Guvante 11y ago
> The arguments against revamping basically boil down to "but that would obsolete this old textbook!" The biggest argument against revamping is breaking tons of existing code. Haskell has been trying to gain traction in industry and randomly breaking existing code is a good way to have people lose faith. Now they have locked themselves into roughly "no breaking changes for three years after initial release". Luckily there has recently been some more progress caused by realizing that online repositories are a great way to validate how much of a breaking change would happen with hypothetical changes, for instance removing the pure/return duality.
- pklausler 11y ago
  I'm not saying that the current Prelude should become unavailable. That would be really stupid.
- marcosdumay 11y ago
  People can (relatively) easily create a Haskell2016 standard with a new default Prelude, and keep the old Prelude by default on Haskell2010 code. Add a compiler switch to set it manually, and it's as trouble-free as it can be. It is great that Cabal pushes people to declare what version of the language they are using. I guess the reason it was still not done is because people do not agree on what the new Prelude should be, if should be a Prelude at all, or if it should be a single one.
maxander 11y ago
Have the Haskell gurus considered doing a Python 3-style update/fork hybrid the explicit purpose of code-breaking changes? Haskell 2?
- pklausler 11y ago
  The discussion is about cleaning up the standard library, not the language. Multiple standard libraries can coexist happily.

pklausler 11y ago

Some specific things that I do in Haskell programs written for production: 1. Define a FutureProofing.hs module that anticipates changes to GHC that are, or now were, inevitable, such as Monad becoming a subclass of Applicative, and "fail" moving out of Monad. I redefine MonadIO to depend on Applicative so that I can use "pure" universally, hiding "return" from Prelude. 2. I have a longish list of things I hide from the Prelude, besides "return" (above). I haven't yet crossed the Rubicon of inhibiting the standard Prelude altogether, but I don't allow myself to use the bad parts. 3. I have a GenericIO.hs module that defines a typeclass that allows me to use any type of string for pathnames or data. This eliminates nearly all boilerplate conversions when dealing with the IO library and anticipates the changes that might eventually come to the standard Prelude. In short, I expect and anticipate the standard library to improve, and will not have to do much work to exploit those improvements when they do arrive. I steer clear of the pitfalls. And unlike the OP, I try to avoid complicating the problem by adding new things to my universal imports; I don't mind having longish import lists at the heads of my modules (and I always enumerate all the names that I import).

koloron 11y ago
If you're still using string types for pathnames you may want to check out the path and path-io packages. The path package defines a Path type parameterized by its locality (absolute or relative) and type (pointing at a file or a directory). Especially the distinction between relative and absolute paths adds a nice safety layer.

Guvante 11y ago

> The arguments against revamping basically boil down to "but that would obsolete this old textbook!" The biggest argument against revamping is breaking tons of existing code. Haskell has been trying to gain traction in industry and randomly breaking existing code is a good way to have people lose faith. Now they have locked themselves into roughly "no breaking changes for three years after initial release". Luckily there has recently been some more progress caused by realizing that online repositories are a great way to validate how much of a breaking change would happen with hypothetical changes, for instance removing the pure/return duality.

pklausler 11y ago
I'm not saying that the current Prelude should become unavailable. That would be really stupid.
marcosdumay 11y ago
People can (relatively) easily create a Haskell2016 standard with a new default Prelude, and keep the old Prelude by default on Haskell2010 code. Add a compiler switch to set it manually, and it's as trouble-free as it can be. It is great that Cabal pushes people to declare what version of the language they are using. I guess the reason it was still not done is because people do not agree on what the new Prelude should be, if should be a Prelude at all, or if it should be a single one.

maxander 11y ago

Have the Haskell gurus considered doing a Python 3-style update/fork hybrid the explicit purpose of code-breaking changes? Haskell 2?

pklausler 11y ago
The discussion is about cleaning up the standard library, not the language. Multiple standard libraries can coexist happily.