type (++) = (<>)

[Vassil Ognyanov Keremidchiev]

"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 <ekmett at 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+hs at 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 at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>
>
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20170704/70bb15bf/attachment.html>