I loved the statement made by Ryan Trinkle in his recent talk [1]: "since we cannot predict all the changes needed the future, we must have an architecture that will support any change" (it's roughly like that, not an exact quote, about 4minutes in). Having to use IFDEFs is a sign that the language itself is not expressive enough to deal with these kinds of changes and therefore it's not having the right "architecture". Is Backpack going to provide the necessary support, (e.g., ability to mix in package fragments with extensions instead of making breaking changes)? What kind of language features are still missing? Anyway, mistakes were made in the past, because had we known any better we would have done better. Nothing should prevent us from fixing mistakes. Regarding IFDEFS, all of them disappeared from my code once I used transformers-compat and mtl-compat. ‎Also the trick with import Prelude worked-you just have to list what you hide instead of what you import (which is weird...).  -- Michał [1] http://www.infoq.com/presentations/functional-techniques-complexity On Mon, Oct 5, 2015 at 2:34 PM, Gregory Collins wrote:

On Mon, Oct 5, 2015 at 8:09 AM, Gershom B wrote:

...

My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one?

This is a multi-year, "boil the ocean"-style project, affecting literally every Haskell user, and the end result after all of this labor is going to be... a slightly spiffier bike shed?

Strongly -1 from me also. My experience over the last couple of years is that every GHC release breaks my libraries in annoying ways that require CPP to fix:

~/personal/src/snap λ find . -name '*.hs' | xargs egrep '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l 64

As a user this is another bikeshedding change that is not going to benefit me at all. Maintaining a Haskell library can be an exasperating exercise of running on a treadmill to keep up with busywork caused by changes to the core language and libraries. My feeling is starting to become that the libraries committee is doing as much (if not more) to cause problems and work for me than it is doing to improve the common infrastructure.

G -- Gregory Collins

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe