foldable flexible bridges (putting foldable+traversable in prelude) Re: Burning bridges

Tue May 21 07:18:00 CEST 2013

I'm not convinced nothing will break. From my experience if you change
anything in such high impact place as Prelude you are unlikely not to break
anything. You are making some functions more generic and this can easily
create ambiguity.

Just try compiling whole Hackage with modified Prelude and see what the
results are.

Best regards,
Krzysztof Skrzętnicki

On Tue, May 21, 2013 at 7:06 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> lets see what concerns there are
>
> 1) will any code break? Nope! In fact, it's trivial to provide a shim that
> only exposes the list monomorphic versions.
>
> 2) does the change make learning the language more challenging? No. In
> fact, i've encountered *many* more smart people getting confused as to why
> the map / fold etc in prelude are all list specific than i've seen people
> struggle with type classes. The various list specific versions of the
> foldable codes actually **confuses** smart software folks who are starting
> to learn haskell for fun.
>
> I can't explain to a smart engineer *any* reason why minimum :: Ord<http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Ord> a
> => [a] -> a
> exists in prelude. I *can* explain why something like minimum :: (Foldable<http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.html#t:Foldable>
>  t, Ord<http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Ord.html#t:Ord> a)
> => t a -> a   would be useful and deserving of being in the standard
> prelue.
>
>  I've actually had to explain to a smart python engineering friend who's
> learning haskell this very problem. (that the list only versions are there
> for no deep reason aside from some pedagogical approach from over a decade
> ago that is no longer used)
>
> tl;dr  no code will break, there will be less inessential nonuniformity
> that doesn't aid in engineering or learning with haskell, so a win in every
> direction.
>
>  lets make things happen.
>
> -Carter
>
> On Mon, May 20, 2013 at 11:04 PM, <amindfv at gmail.com> wrote:
>
>> Whoa! I don't think that replacing list-monomorphic functions in the
>> prelude with more-general ones is going to cause the community to split
>> down the middle!
>>
>> Most of the changes we're talking about won't even break any legacy code!
>> Of course, some typeclass-rearranging will break things, but not the
>> prelude replacements that we've been discussing. The biggest impact is that
>> existing teaching texts may have old information about the type signatures
>> of standard functions.
>>
>> As much as I *love* imagining the Haskell community in a bridge-burning,
>> rival GHC HQ deathmatch (Simon vs. Simon! Edward vs. Edward!), I really
>> think this change won't attract the interest of any tabloids.
>>
>> That said, I definitely agree that it should take more than a few +1s to
>> move this forward. I'd suggest a relative-consensus on the libraries list,
>> then a "Here's our plan; are we crazy?" email on haskell-cafe.
>>
>> Tom
>>
>>
>> El May 20, 2013, a las 6:59 PM, Felipe Almeida Lessa <
>> felipe.lessa at gmail.com> escribió:
>>
>> > IMHO, the problem is that the community isn't large enough to be able
>> > to suffer a split.  Case in point: how are we going to have two GHC
>> > HQs?
>> >
>> > If we're going to burn bridges, perhaps we should follow a
>> > Python-3-esque path of releasing a major upgrade together with:
>> >
>> >  - A refactoring tool to aid with the transition.
>> >
>> >  - A deadline of, say, 2-3 years during which the latest GHC for
>> > current Haskell would receive bugfixes while GHC 8 moves along as
>> > usual.
>> >
>> > Cheers,
>> >
>> > On Mon, May 20, 2013 at 7:49 PM, wren ng thornton <wren at freegeek.org>
>> wrote:
>> >> On 5/19/13 7:25 PM, Anthony Cowley wrote:
>> >>>
>> >>> I think this issue may be too big to rely on mailing list +1s. Is
>> there
>> >>> any precedent for having a web-based poll of some sort? We often get
>> more
>> >>> engagement in debates on IRC and /r/haskell than the mailing list, so
>> let's
>> >>> not let the choice of forum drive the result.
>> >>
>> >>
>> >> Indeed.
>> >>
>> >> Personally, I'm all for blessing Foldable/Traversable as "built-in" and
>> >> getting rid of the monomorphic legacy. But then, I'm also all for
>> making
>> >> Applicative a superclass of Monad, not having all the mtl modules
>> re-export
>> >> everything from Control.Monad, etc. However, all of these issues have
>> a long
>> >> history of discord, and that discord cannot be resolved on this list
>> IMO.
>> >>
>> >> 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.
>> >>
>> >> Let us not forget the original reasons for many of these warts. Some
>> of them
>> >> stem from ignorance or oversight (superclasses of Monad); others stem
>> from
>> >> the desire to help newcomers (monomorphism); and others stem from
>> >> circularities in the language definition (the existence of the
>> Prelude). As
>> >> Haskell has developed, we have learned more ---therefore we should not
>> >> embrace prior ignorance---, our standard idioms have evolved
>> ---therefore
>> >> clinging to list-monomorphism *causes* confusion rather than
>> alleviating
>> >> it---, and we've tried to remove much of the circularity involved in
>> >> desugaring the various built-in notations for lists, arithmetic
>> sequences,
>> >> do-notation, etc.
>> >>
>> >> 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. This won't
>> solve
>> >> all the problems, of course. We will still despair of the numeric
>> hierarchy;
>> >> we will still despair of the partial functions demanded by the Haskell
>> spec;
>> >> we will still worry about how to resolve things like MPTCs, type
>> families,
>> >> and all that. But at least we can finally put these particular ghosts
>> to
>> >> rest. Alas, to fork the language is to split the community. And while I
>> >> advocate such drastic measures, they are measures which cannot be
>> resolved
>> >> either on this list or by the (intentionally conservative) haskell'
>> >> committee.
>> >>
>> >> --
>> >> Live well,
>> >> ~wren
>> >>
>> >> _______________________________________________
>> >> Libraries mailing list
>> >> Libraries at haskell.org
>> >> http://www.haskell.org/mailman/listinfo/libraries
>> >
>> >
>> >
>> > --
>> > Felipe.
>> >
>> > _______________________________________________
>> > 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
>>
>
>
> _______________________________________________
> 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/6121f5a8/attachment.htm>