<br><br><div class="gmail_quote">On Tue Feb 03 2015 at 6:29:51 PM Herbert Valerio Riedel <<a href="mailto:hvr@gnu.org">hvr@gnu.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015-02-03 at 16:45:22 +0100, Michael Snoyman wrote:<br>
<br>
[...]<br>
<br>
> * I have many other complaints about the standard Prelude: partial<br>
> functions like `head` and lazy I/O being a recommended default being<br>
> primary in that list.<br>
<br>
I think most of us are unsatisfied with the current status quo, which is<br>
why the BBP manifesto got so much attention (of which the FTP is just<br>
one of the laundry-list items).  But we have to start somewhere and<br>
rather incrementally, like e.g. low-hanging fruits such as the FTP,<br>
before addressing the more complicated items on that manifesto.<br>
<br>
> * I've personally moved on from the default Prelude and regularly use<br>
> alternate preludes in my own code (classy-prelude being the most common<br>
> example, but others existing too). I'm not the only person who does this,<br>
> and it solves a lot of the problems.<br>
<br>
So basically you don't have any stake in the default Prelude anymore? ;)<br>
<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
More seriously, there's one downside to the proliferation of alternate<br>
Preludes I'm worried about: While they allow for easy experimentation<br>
(which is great but hardly useful to base production code on), they also<br>
fragment the Haskell-language, as each alternate Prelude is actually a<br>
different dialect of Haskell.<br>
<br></blockquote><div><br></div><div>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.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Having a common Prelude providing the common vocabulary that allows all<br>
sub-cultures to co-exist while balancing all/most needs helps keeping<br>
the language united. The more the default Prelude fails to satisfy its<br>
job of keeping up with the times, the less incentive there is not to<br>
resort to create alternative Preludes and suffer from Haskell's<br>
version of the Tower-of-Babel.<br>
<br>
So when in future scenario like that you talk about "Haskell", you'll<br>
have to specify which prelude-version of Haskell you mean, and also make<br>
sure you pick the respective literature that covers that specific<br>
prelude-dialect. And each dialect can potentially lock you into<br>
different sub-ecosystem of packages. I'm aware this is extrapolating<br>
quite a bit, and it doesn't necessarily have to come to such extremes.<br>
<br>
Cheers,<br>
  hvr<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Michael</div></div>