I think the problem with different stability in different parts of base is that it makes it very difficult for package maintainers to get an accurate set of bounds. If you write base >= 4.8 && < 5 you may later need to revise the bounds, and if you write base >= 4.8 && < 4.12 you will likely have bounds be too strict (which may not be revised for every package version...).

I had the impression that splitting base would be done using backpack, so that you could provide alternate base implementations for e.g. GHCJS.

There's a 4 year-old trac ticket here which has some other stuff. There, it talks about user-provided base implementations as the advantage rather than versioning. I think this approach is likely to provide the biggest improvements without breaking anything.

Am Di., 30. Okt. 2018 um 16:32 Uhr schrieb Daniel Cartwright <chessai1996@gmail.com>:

DOA seems kinda harsh at this point.

I think "DOA" is the right description for every proposal touching the foundations of a language ecosystem in an incompatible way *unless* there are very, very good reasons to break things. And even then, you should better have a good migration story. Python 3 anybody?

 

If base just re-exports the stuff, that makes sense, but wouldn't we want to move it out eventually?

Hmmm, what problem exactly should be solved by splitting base? Has this been written down somewhere? Edward mentioned different stability in different parts of base, which is certainly true, but do we have concrete convincing examples of problems caused by that? Does a migration story exist? I just want to remind everybody about the trouble and effort involved in pushing the AMP and FTP through the ecosystem, which are probably peanuts compared to a reorganization of base...

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries