I understand. Thank you! 2017-07-04 15:38 GMT+03:00 Edward Kmett <ekm...@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 < > var...@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 <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
