Drastic Prelude changes imminent

[Bardur Arantsson]

On 01/31/2015 08:57 PM, Yuras Shumovich wrote:
> On Sat, 2015-01-31 at 09:59 -0800, Johan Tibell wrote:
>> Which is terrible. Alternatively I can write
>>
>>     import qualified Data.Foldable as F
>>
>> but now nothing is gained over the pre-FTP state. Only after 3+ years (at
>> the current GHC release phase) I can drop that one extra import. One out of
>> perhaps 20. That seems quite a small gain given that we will then have made
>> Data.List a very confusing module (it's essentially Data.Foldable under a
>> different name), broken some code due to added type ambiguity, and also
>> removed one of the simpler ways to remove that ambiguity, which would have
>> been to import one of the monomorphic list functions that no longer exist.
>>
>> * People tell me that there are other goals, but they aren't really stated
>> clearly anywhere.
> 
> I'd like to known other goals. Right now it looks for me like saving few
> keystrokes.

Personally, I think I've come to the conclusion (from the various
discussions around here and on Reddit) that there probably shouldn't
*be* any Prelude. Either that or Backpack is unfortunately about 5-10
years too late in the making. (Hopefully it'll get there!).

Universities and books could still have their own pre-built
"SitePrelude", but at least random re-exported modules wouldn't be
constrained so much by that.

Of course, then we'd probably be arguing about Data.List, but at least
"the world" wouldn't break. SitePrelude could also be a point to
"contain the damage", so to speak.

However, I certainly agree with Gershom B that the "enterprise" people
are exactly the kind of people who have the means to prevent these
problems affecting *them* too much. They probably should be (or are
already) doing due dilligence to that effect.

I'm sure I'm preaching to the choir, but one of the reasons Haskell is
so great is that *most* semantics-changing changes in libraries actually
break code *loudly* rather than *silently*. (And, I for one, appreciate
the HLCs efforts to avoid silent breaking changes due to this change.)
Usually, IME at least, loud breaking changes aren't actually that hard
to fix, though I definitely have sympathy for library authors with huge
numbers of revdeps :/.

I wonder if there's something to be learned from "go fix"[1] in terms of
making it a first-class citizen in the ecosystem. I suspect that a
Haskell equivalent could even be taught to maintain/remove "cpp+version"
blocks, etc.

[1] https://golang.org/cmd/fix/

Regards,