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

newer
[ANN] first release of http2-client

older
Where is the hole?

Doug McIlroy

3 Jul 2017 3 Jul '17

1:29 p.m.

...

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

Show replies by date

Lana Black

4 Jul 4 Jul

7:05 a.m.

New subject: type (++) = (<>)

On 03/07/17 17:29, Doug McIlroy 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

Using MonadPlus in this case is not the best idea. There are types that can implement (++) but aren't a Monad. Data.Set is one example.

Edward Kmett

8 Aug 8 Aug

12:30 p.m.

New subject: type (++) = (<>)

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 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 Only members subscribed via the mailman list are allowed to post.

Jacques Carette

12 Aug 12 Aug

9:57 a.m.

New subject: type (++) = (<>)

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 mailto:doug@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.

2838

Age (days ago)

2878

Last active (days ago)

List overview

Download

3 comments

4 participants

participants (4)

Doug McIlroy
Edward Kmett
Jacques Carette
Lana Black