[Haskell-cafe] type (++) = (<>)

[Jacques Carette]

This piece of reasoning, if endorsed by the libraries team, should be 
recorded somewhere else than just email.  Although I am not a fan of 
language-design-by-history, the chain of events is at least extremely 
clear and rather defensible.

Jacques

On 2017-08-08 12:30 PM, Edward Kmett wrote:
> There was a great deal of monomorphization that went into the Haskell 
> 98 standard under the nominal goal of trying to help newcomers to the 
> language with simpler error messages. For more you can read old 
> mailing list posts from that timeframe.
>
> As a technical aside, (<>) is used for Monoid (and soon will upgrade 
> to Semigroup) not MonadPlus, so the symbols have diverged in 
> sentiment. Not only that, but (++) and (<>) get mixed in existing 
> pretty printing code a good deal, and have different fixities, and 
> must, lest a bunch of code silently change semantics. This was one 
> reason why (<>) was added (to match existing practice in the pretty 
> printing libraries) rather than generalizing (++).
>
> Once we've added (<>), generalizing (++) becomes less urgent and 
> actually has some cons. Notably, there is a subset of the community 
> that finds the current form of map and (++) potentially useful for 
> teaching about lists. If they generalized to become fmap and (<|>) or 
> (<>) then we create a redundant notation for an existing thing, with 
> no roadmap for replacing one with the other, and lose the teaching tool.
>
> As a general guideline, the core libraries committee has been trying 
> to avoid introducing redundant names that have the exact same type 
> signature, with possibly different fixity, but where one is exported 
> from the class and the other isn't, because it makes it yet another 
> detail you have to memorize to know which one is the one in the class 
> and can be refined: the types simply don't tell you.
>
> Having one version that is strictly more general enables one subset of 
> the community to simply forget about the other one and move on, and 
> another subset that aren't fans of rampant abstraction to use the one 
> with more specific type when they want to clearly signal intent.
>
> I'd be slightly more open to discussions about eventual removal or 
> exile of the redundant members to an appropriate module than 
> generalization under that guideline, but that isn't a hill I'd want to 
> die on. (++) is pretty well embedded in Haskell's DNA.
>
> *tl;dr* It happened at first because of a great wave of 
> monomorphization, and there is at least a defensible reason why it 
> hasn't generalized back in the presence of other changes that have 
> happened in the meantime.
>
> -Edward
>
> On Mon, Jul 3, 2017 at 1:29 PM, Doug McIlroy <doug at cs.dartmouth.edu 
> <mailto:doug at cs.dartmouth.edu>> wrote:
>
>     > What do you think of making (++) the same as (<>)
>
>     This seems to be a call for returning to the old situation in
>     which (++) was an operator of class MonadPlus. Why was that
>     abolished in Haskell 98?
>
>     Doug
>     _______________________________________________
>     Haskell-Cafe mailing list
>     To (un)subscribe, modify options or view archives go to:
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
>     Only members subscribed via the mailman list are allowed to post.
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170812/5d53d70b/attachment.html>