Re: Burning bridges
Casey McCann <cam <at> uptoisomorphism.net>
2013-05-21 14:33:33 GMT
On Tue, May 21, 2013 at 2:57 AM, Edward Kmett <ekmett <at> gmail.com> wrote:
> 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.
RSS Feed