On Tue Feb 03 2015 at 6:29:51 PM Herbert Valerio Riedel <hvr@gnu.org> wrote:
On 2015-02-03 at 16:45:22 +0100, Michael Snoyman wrote:

[...]

> * I have many other complaints about the standard Prelude: partial
> functions like `head` and lazy I/O being a recommended default being
> primary in that list.

I think most of us are unsatisfied with the current status quo, which is
why the BBP manifesto got so much attention (of which the FTP is just
one of the laundry-list items).  But we have to start somewhere and
rather incrementally, like e.g. low-hanging fruits such as the FTP,
before addressing the more complicated items on that manifesto.

> * I've personally moved on from the default Prelude and regularly use
> alternate preludes in my own code (classy-prelude being the most common
> example, but others existing too). I'm not the only person who does this,
> and it solves a lot of the problems.

So basically you don't have any stake in the default Prelude anymore? ;)


Essentially, yes. This isn't really true: as a library author, I still typically use the standard Prelude. But in my application code, I almost never reach for the standard Prelude anymore.
 
More seriously, there's one downside to the proliferation of alternate
Preludes I'm worried about: While they allow for easy experimentation
(which is great but hardly useful to base production code on), they also
fragment the Haskell-language, as each alternate Prelude is actually a
different dialect of Haskell.


I disagree; I think code using classy-prelude, basic-prelude, base-prelude, and others all looks very much like idiomatic, standard Haskell code, based around functions like map, filter, mapM_, etc. Conversely, there are some libraries out there that are *not* Prelude replacements but I'd argue do much more to create a different dialect of Haskell. (I'm specifically *not* listing such libraries as that's not the point of this conversation.)
 
Having a common Prelude providing the common vocabulary that allows all
sub-cultures to co-exist while balancing all/most needs helps keeping
the language united. The more the default Prelude fails to satisfy its
job of keeping up with the times, the less incentive there is not to
resort to create alternative Preludes and suffer from Haskell's
version of the Tower-of-Babel.

So when in future scenario like that you talk about "Haskell", you'll
have to specify which prelude-version of Haskell you mean, and also make
sure you pick the respective literature that covers that specific
prelude-dialect. And each dialect can potentially lock you into
different sub-ecosystem of packages. I'm aware this is extrapolating
quite a bit, and it doesn't necessarily have to come to such extremes.

Cheers,
  hvr

I disagree with this argument. When I use the standard Prelude, I almost invariably import 15 or so other modules, from standard ones (Control.Exception) to specific libraries (Data.Vector). Sub-ecosystems in that sense necessarily exist, and making the Prelude incrementally better is unlikely to change that in any meaningful way.

We could have a central Haskell committee that blesses an official packed data representation library (vector), chooses a CSV library, anoints a streaming data library (fat chance), and *then* we'll avoid the sub-ecosystem. Until then, I don't really see the question of whether `mapM_` works on a list or any Foldable as causing Haskellers to speak different languages.

Michael