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

Tue May 21 07:06:18 CEST 2013

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130521/d13f67f5/attachment-0001.htm>