type (++) = (<>)

Tue Jul 4 16:28:36 UTC 2017

I understand. Thank you!

2017-07-04 15:38 GMT+03:00 Edward Kmett <ekmett at gmail.com>:

> Yes, I attempted to address why this was left unmolested in my last couple
> of paragraphs.
>
> For comparison, we have not generalized map to have the same signature as
> fmap because we do not have to. fmap already exists,
> having the less general signature directly indicates why it isn't possible
> for you to use
>
> instance Functor Foo where
>   map = ...
>
> and a large portion of the community would like it to remain ungeneralized
> (often for teaching purposes).
>
> Given that we already have a polymorphic combinator in Prelude there is no
> need to make their teaching tool more awkward to teach with. As it is,
> teachers already have to get into typeclasses before they can talk about
> foldr, and this already causes a fair bit of consternation.
>
> If we had everything to over again and no installed base? I'd probably say
> map should have been the member of Functor, like it is in most other
> languages that have anything even remotely resembling type classes at this
> point. The pain of transition doesn't warrant it, however.
>
> Similarly, (<>) is winding up in Prelude as part of the Semigroup/Monoid
> proposal. (++) was explicitly un-generalized in Haskell 98 for teaching and
> error purposes, and we have (<>) present and moving into Prelude, so there
> isn't a real reason to go and generalize the second name and there is at
> least a weak justification for leaving the status quo in place.
>
> Having two operators for the same thing means another side-condition to
> learn, another quirk to learn, etc. You still need to memorize which one
> you are allowed to define in Semigroup. The folks who write that same
> fiddly kind of pretty printer code do derive some benefit from keeping
> those operators separate.
>
> Finally, The status quo at least lets us dream the dream that we could
> remove (++) entirely from the language some day. (Even if we're unlikely to
> act on this impulse due to the fixity concerns raised above.)
>
> -Edward
>
> On Tue, Jul 4, 2017 at 3:31 AM, 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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20170704/8d4148f2/attachment-0001.html>