I'm sorry for being so behind the times, and now have to write this at this stage...
BBP deeply saddens me. While I understand the desire for a more generalized Prelude (surely this is one of the seven stages of Haskell, along with "need to write a Monad tutorial"....), I don't think the ends come anywhere close to justifying the means.
I realize I'm often (always?) the voice of stodginess. But I'll tell where I'm coming from: I want to get people to adopt Haskell for serious software development. But that means I have get them to buy into an ecosystem and for them to do so they need to feel it will be stable on the order decades. They need to feel that before they're going to be willing to invest in the tooling, the process development, and committing their work to Haskell.
In 1990 most shops wouldn't ship software in C++ because none of us trusted the compilers, or that language (already C++ 2.0) wouldn't change in ways that would be unpredictable and negatively affect our work. It took almost another decade. In 2005 many places still wouldn't ship things using STL. It takes a long time for people to trust that an ecosystem has stabilized.
"Burning Bridges". The name says it all. We cannot do this. We have to look well beyond how a change like this affects compiling a bunch of code form stackage... We have to think beyond the discussions on our mailing lists... Think of the text books, the corse syllabuses, the in-house trainings, think of work flow and deployment processes.. think of vast amounts of code we can't see... We cannot undermine the Prelude and Data.List that they are all built on.
If we make a change like this, we've just told the world to wait another 10 years before considering Haskell.
The sadder thing is that I don't think the proposal really adds much to Haskell:
The value of generalizing the list functions greatly over estimated: There have been alternate, more generalized Preludes for ages... and I don't see much use of them. Sure, they require some futzing with imports to use - but that isn't that high of a bar, and yet clearly their value rarely merits it in people's minds. Maybe I don't write the most clever code (code golf excepted), but I rarely pine for a more generalized length. Or for all to work over Foldable... etc.
For the few times when I need something like Foldable I don't see what the issue is with importing qualified and using prefixes. People here seem to feel that a "F." is somehow an ugly wart on their code... but that is just the way it is with most software: You need a lot of things in scope, you use namespaces of one sort or another.
There's also a whole issue of commitment to forward and backward compatibility that we as a community don't yet have. Littering our code with CPP is not really acceptable. And all production code insists on clean compilation with -Wall, so we can't be spewing warnings. Or for that matter playing tricks with import orders. This stuff is tricky and hard... no doubt, but it is the price of a bid at adoption.
All in all, what saddens me here is that this whole episode, like the similar one around roles and 7.8, is indicative that on the whole, we as a community, are not ready to hunker down and work toward making Haskell a solid tool for software development. We are, instead, too fascinated with making it more perfect.
- Mark