"plus" symbol is natural denoting joining two pieces in almost all languages. That is why I would like not to get rid of it, but to be a bit more general. So in new code that will use the new prelude to be able to use it on broader range of containers (monoids/semigroups).
I really mean: (++) :: Semigroup s => s -> s -> s About the fixity, it could retain it's original fixity. 2017-07-04 3:24 GMT+03:00 Edward Kmett <ekm...@gmail.com>: > Note: I realize nobody is directly saying that we should use (++) instead > of (<>) in this conversation just yet, but I want to clear a few things up. > > One of the early options when the operator (<>) was coined was to try to > say we should just generalize the type of (++) instead to make it mappend. > (Note: it originally was mplus, in a Haskell version long long ago, so it > keeps getting repurposed!) Unfortunately, this plan ran afoul of the fact > that the primary libraries using the (<>) notation at the time (pretty > printing libraries) also mixed it heavily with (++), exploiting the > different fixities involved. (Finding a decent fixity for (<>) was a huge > chunk of the conversation at the time.) > > There is a deliberate fixity difference between (++) and (<>), a good > chunk of code out there mixes them that deals with pretty printing that > would break pretty horribly if we just outright removed (++), and trying to > do a visual search and replace for (++) with (<>) in light of them having > different fixities is a very error prone process, so we aren't currently > planning on deprecating the existing (++) operator any time soon. At least, > nobody has put a proposal to the core libraries committee to that end. > > Since the call was made to make (<>) become the new operator, we > ultimately decided to leave (++) untouched, even though it could be > generalized to match (<>), for much the same reason that map still exists, > despite there being a more general fmap: Ultimately, there isn't a > reasonable migration plan to make (++) or map become the way you define the > instance involved, and at least this way the name duplication can be > leveraged by the folks who want a less polymorphic combinator. > > Would the world be a little tidier without map or (++) hanging about? > Sure. But the hate mail levels in my inbox would skyrocket commensurately. > ;) > > -Edward > > On Mon, Jul 3, 2017 at 5:01 PM, Erik de Castro Lopo <mle...@mega-nerd.com> > wrote: > >> Vassil Ognyanov Keremidchiev wrote: >> >> > What do you think of making (++) the same as (<>) so we could use ++ as >> > concatenation of any monoid, not just lists in Haskell 2020? >> > This will be more intuitive for beginners, too. >> >> Two symbolic operators that are synonymous seems a bit of a waste. I would >> much rather see (++) be deprecated in favour of (<>). At work we have a >> custom prelude which already does this. >> >> Erik >> -- >> ---------------------------------------------------------------------- >> Erik de Castro Lopo >> http://www.mega-nerd.com/ >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >> > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > >
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
