I do strongly believe that bringing Foldable and Traversable into the Prelude and replacing the monomorphic variants would actually be a fairly painless change.
During the transition some people would be forced to manage explicit import lists for their packages. We've paid for this with 'catch', the 'Num' transition, 'Bits', etc. and we're pretty good at managing this sort of change by now.
I agree with those points, however they are a little (for the lack of a better word) single-cased, therefore I'm not sure how well they transfer to new scenarios. The catch/Num transitions are on a much smaller scale than what has been discussed here after all. I think the main issue we'll have to address here is inertia, more specifically how much more people value inertia over the proposed changes, no matter how good they are. I'm just going to throw this idea out there: what would you think about adding warnings to GHC specifically for the transition, think of meta-deprecations? Examples: - Use the (more) polymorphic functions from Foldable/Traversable - Please also define Functor/Applicative for your Monad Potential benefits: - During the GHCi-based workflow that I use, as I am sure many others do, this would help me not to forget or ignore doing these things. Sometimes it may be more convenient just to take what Prelude gives me (call it the "whatever, it works for now" attitude), but when a warning is nagging me I'll think "alright, it's for the greater good™ so I'll add the import". - GHC's ability to point the user to the location of an error is quite amazing. Equipped with this, fixing other (possibly unmaintained) modules would probably by very easy. - -fno-transitional-warnings could disable these messages for a warning-free build I realize adding this may be a bit hacky, as GHC knows nothing about Applicative/Foldable/..., so the warnings will be hardcoded. However, I would consider this a transitional implementation detail far outweighed by its benefits. David PS: I'm aware this is (again) a post that arguably belongs to the ghc-dev list, but I think it goes well with this discussion.