Burning bridges

[Carter Schonwald]

well said,


On Tue, May 21, 2013 at 2:57 AM, Edward Kmett <ekmett at gmail.com> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/c7507f26/attachment-0001.htm>