
Building a Better Custom Haskell Prelude - ingve
http://www.stephendiehl.com/posts/protolude.html
======
pklausler
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".

~~~
Guvante
> 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.

~~~
marcosdumay
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.

------
hesselink
It's interesting how different people's preludes are. We have a custom prelude
at work, and things that it has that this one doesn't:

* Time types and functions.

* Overloaded (.) and `id`, and some arrow functionality. * More from 'safe'.

* Semigroup.

* String conversions from 'string-conversions', type synonyms for both lazy and strict Text and ByteString types.

* Vector and UUID.

What we don't have:

* The monad transformers by default, although maybe we should.

* Generics. Again maybe we should.

* Bits, Complex.

* All the custom implemented improvements.

* Semiring, DeepSeq, the containers types, concurrency.

Basically our prelude is more conservative, I guess, although it identifies
and solves a lot of the same problems. Perhaps that is some common ground to
start doing small improvements to the "real" prelude.

------
LukeHoersten
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.

~~~
runchberries
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...](http://stackoverflow.com/questions/6364409/why-does-haskells-
head-crash-on-an-empty-list-or-why-doesnt-it-return-an)

~~~
drostie
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
With `[a] -> Maybe a`, it's not so bad if you use `catMaybes` from Data.Maybe.

map transform . catMaybes . map safeHead

~~~
koloron
Even better with mapMaybe:

    
    
        map transform . mapMaybe safeHead

------
js8
What about classy-prelude? I was thinking about using that one.. (based on
Stephen's advice in the other blog post
[http://www.stephendiehl.com/posts/production.html](http://www.stephendiehl.com/posts/production.html))

Has anyone experience with it, pros, cons?

~~~
danidiaz
classy-prelude is a "Big Vehicle Prelude", that is, a Mahayana Prelude.

~~~
burkaman
What does this mean?

~~~
danidiaz
Sorry, dumb joke. Mahayana Buddhism is also known as "big vehicle" or "great
vehicle" Buddhism.

~~~
burkaman
Yeah I got that from Wikipedia, I just don't know what you mean by describing
it as "big vehicle". Like it's bloated, or too broad or something?

~~~
dsp1234
FTA:

 _" Big Vehicle Prelude - Fix most of the deficiencies in the Prelude by
introducing new abstractions that replace large portions of the basic types
and class, and generally redefine the way we write Haskell. See numeric-
prelude.

Small Vehicle Prelude - Fix the broken parts of the Prelude by building on
existing types and classes and masking broken bits. See basic-prelude."_

~~~
burkaman
Oh oops, I guess I skimmed over the intro

------
davnn
Stephen Diehl is a good example of a content creator that a lot of people
would love to send their money to :-)

------
z1mm32m4n
> The Haskell Prelude is the default import into all Haskell modules, it
> provides an endless number of ways to shoot ourselves in the foot and
> historical cruft that can’t be removed.

As someone who's only recently started using Haskell seriously, what are some
items from this "endless" list of things? Coming from a Standard ML
background, one thing about Haskell that I prefer is that the Prelude is so
powerful on it's own; SML's set of top-level functions is pretty limited.

~~~
nv-vn
Yep, same here coming from OCaml. MLs seem a lot more conservative with their
standard libraries. Actually, with OCaml there have been a ton of attempts at
making the standard library larger (Extlib, Batteries, Containers, Core, etc.)
which is pretty much the opposite of what people are doing with Haskell. I
always end up midsing Prelude when I'm working in OCaml, so it feels weird to
me that people would want to strip it down so much.

~~~
JadeNB
I think the prevalence of articles like this one, about what's wrong with the
Prelude, are exactly the reason for the impulse not to have such a big stdlib.
If Haskell's were more modularised, then there wouldn't be this perpetual
dissatisfaction with it (although, of course, there might be different
dissatisfactions); you could just slice'n'dice it into the shape you wanted.

------
imh
What are people's thoughts about using constraint kinds in the prelude, so you
can make things with class constraints monads? Like making a Set monad.

This stack overflow answer shows what I'm talking about
[http://stackoverflow.com/a/22314189/1080531](http://stackoverflow.com/a/22314189/1080531)

