Burning bridges

[Edward Kmett]

I raised the issue mostly to remind everyone that it still existed and that
the status quo is quite awkward. I was going to let this rest, but as it
seems to still be stirring up a passionate response, I felt it necessary to
reply again.

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.

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.

The combinators in Data.Foldable and Data.Traversable simply subsume all of
the other redundant versions of them that occur in base.

Sure there are reasons why other libraries have chosen to replicate large
portions of the API from Base for particular data types with particular
constraints, but those are just that -- other libraries.

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.

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.

I for one would hate to lose them from the vocabulary of the Prelude.

-Edward


On Tue, May 21, 2013 at 2:22 AM, Simon Peyton-Jones
<simonpj at microsoft.com>wrote:

> | I'm generally a staunch advocate of backward compatibility. However,
> | these issues are ones where we've known the right answer for a long time
> | (unlike refactoring the numeric type class hierarchy), and we've simply
> | been unwilling to burn bridges in order to do the right thing. I love
> | Haskell, and I respect the haskell' committee, but I think it's time to
> | just burn it all down.
> ...
> | With all that has changed in the last 15 years, I think it's high time
> | to fork Haskell, tear off all the bandaids, and begin afresh.
>
> I'm not sure what you are proposing, concrete, by "fork Haskell".
>
> I think you are simply proposing some non-backward compatible library
> changes. Correct? And yes, it seems reasonable to do that every now and
> again. Indeed there's an active thread on splitting the base package
> http://hackage.haskell.org/trac/ghc/wiki/SplitBase, partly to make it
> easier to build a backward-compatible shim package.  So how
> non-backward-compatible would it all be?
>
> I assume you guys have talked this to death, but is there no way to move
> on, while leaving a backward-compatible API?
>
> Simon
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130521/01bd8821/attachment.htm>