type (++) = (<>)

[Cale Gibbard]

On the other hand, it's unusual, at least in my mind, for "plus" to be used
as notation for an operation which is noncommutative. (++) is something
else of course...

While I can see moving in that direction being reasonable the migration
path is a political nightmare as Edward points out.

I'm *reasonably* happy with the status quo, apart from the fact that I need
to be careful a little too often whether (<>) refers to the Semigroup or
Monoid operation at the moment. Moving Semigroup into base and getting
those two unified would be nice. But this is really all more of a libraries
issue than a language issue.

I'd actually be happy to move almost all discussion of libraries out of the
Report proper, aside from what's minimally required in order to talk about
the meaning of language constructs (e.g. you need Bool to talk about
if-expressions, and Monad in order to discuss do-expressions, and various
bits and pieces like Storable in order to discuss FFI).

To whatever extent it can, The Report should tell us all the stuff about
the meaning of code that reading the libraries can't tell us.

On Tue, 4 Jul 2017 at 03:33 Vassil Ognyanov Keremidchiev <varosi at gmail.com>
wrote:

> "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
>>
>>
> _______________________________________________
> 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/d08b068f/attachment-0001.html>