On Tue, May 21, 2013 at 2:57 AM, Edward Kmett
Type inference has been raised as a factor, but I respectfully disagree that is is a problem in practice with (the bulk of) this proposal. A case may definitely be made that perhaps a few of the combinators, e.g. concat and concatMap should remain monomorphic, but by and large I feel it would dramatically reduce import confusion to only have base only contain one version of each combinator that it exports.
I would be interested to see a real example of existing code of anywhere near production quality that would break due to type inference issues. For breakage to happen, the combinators must be used in such a way that [] cannot be inferred by other means and an appropriate Foldable/Traversable constraint cannot simply be inferred instead. Neither class provides a means for constructing values of an instance type ex nihilo and lacking anything like an Unfoldable class the "show . read" situation is unlikely. Anything applied to a list will be inferred in the usual manner. Definitions with no type signature, subject to the DMR, and not used in the module that defines them should be excluded by "anywhere near production quality". Short of folding a list which was constructed entirely by way of MonadPlus or similar I can't see where problems would arise. Am I missing something here? Beyond that, the argument that having redundant, less-polymorphic versions of standard combinators is helping beginners has not become any less ridiculous since the first time I heard it. These beginners still have to cope with typos that lead to GHC suggesting nonsense such as writing a Num instance for "[Char] -> a2", while on the other hand unnecessary duplication and redundancy absolutely cause problems. On more than one occasion I've explained to a beginner confused by the difference between map and fmap that the sole reason they differ is to avoid confusing beginners. Doubleplus ungood, my friends.
Moreover, if Applicative can ever be made a superclass of Monad, half of the combinators in can Data.Traversable melt away and so can several of the ones in Data.Foldable, reducing the footprint further.
Which would be a fantastic improvement in multiple ways.
I tend to disagree with Ian that mapM, etc. should simply be removed from the Prelude completely. Foldable and Traversable -- unlike almost everything being debated to death in the base split -- aren't things that require heavy machinery. There are no exceptions in them, nothing that is difficult to implement across platforms or compilers. The sum total of language support for them is the DeriveFoldable and DeriveTraversable extensions. They are also quite ingrained in the 'culture' of Haskell.
Those combinators (or the unnecessarily monomorphic counterparts thereof) are also often used unqualified in code such as nearly all of it, found in packages such as nearly all of them. If we're going to remove mapM &c. from Prelude and thereby break everything everywhere, we should at least do something useful along with it, like replace the entire hierarchy of numeric classes.
I for one would hate to lose them from the vocabulary of the Prelude.
I would hate to see the common vocabulary of Haskell code reduced. Let's not invite the Tower of Babel scenario (any more than we already do) where everyone has their own preferred set of libraries for common tasks with no useful, mutually intelligible intersection between them. For all its problems, the current Prelude at least provides a decent foundation for accomplishing common tasks. - C.