On Tue Feb 03 2015 at 6:29:51 PM Herbert Valerio Riedel
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