Drastic Prelude changes imminent

[Michael Snoyman]

On Tue Feb 03 2015 at 6:29:51 PM Herbert Valerio Riedel <hvr at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150203/48bf94fd/attachment.html>