Re: type (++) = (<>)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: type (++) = (<>)

Doug McIlroy
> What do you think of making (++) the same as (<>)

Before Haskell 98, ++ was an overloadable operator associated with
class MonadPlus. Why was that arrangement abolished?

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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: type (++) = (<>)

Doug McIlroy
> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: type (++) = (<>)

Lana Black
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.
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: type (++) = (<>)

Edward Kmett-2
In reply to this post by Doug McIlroy
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 <[hidden email]> 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.


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[hidden email]> 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.



_______________________________________________
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.



_______________________________________________
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.
Loading...