Proposal #3339: Add (+>) as a synonym for mappend

[Bryan O'Sullivan]

Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339

From the ticket:

This proposal was, I think, originally suggested by Jules Bean. The idea is to add two functions to the Data.Monoid module, (+>) and (<+), corresponding to different uses of mappend. These should not be methods of the Monoid typeclass, but top-level functions.

I hope (but slightly doubt) that the visual nature of the two operators might help to counter the thought that monoids are just for gluing things together.

(+>) :: (Monoid a) => a -> a -> a
a +> b = a `mappend` b

(<+) :: (Monoid a) => a -> a -> a
a <+ b = b `mappend` a

infixl 4 +>
infixl 4 <+

Proposed deadline: two weeks.

If this looks reasonable, I'll attach darcs patches.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Edward A Kmett]

Bikeshedding: Would it be better to put the definition for +> (or better yet <>) in the dictionary for Monoid with a circular definition for mappend? That way new code defining Monoid instances can avoid ever having to even mention mappend. I'm ok with it either way. I admit adding it to the dictionary might add dictionary passing overhead and risk inconsistent definitions of <> and mappend.

 

-Edward Kmett

On Tue, Jun 30, 2009 at 5:37 PM, Bryan O'Sullivan <[hidden email]> wrote:

Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339

From the ticket:

This proposal was, I think, originally suggested by Jules Bean. The idea is to add two functions to the Data.Monoid module, (+>) and (<+), corresponding to different uses of mappend. These should not be methods of the Monoid typeclass, but top-level functions.

I hope (but slightly doubt) that the visual nature of the two operators might help to counter the thought that monoids are just for gluing things together.

(+>) :: (Monoid a) => a -> a -> a
a +> b = a `mappend` b


(<+) :: (Monoid a) => a -> a -> a
a <+ b = b `mappend` a

infixl 4 +>
infixl 4 <+

Proposed deadline: two weeks.

If this looks reasonable, I'll attach darcs patches.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Wolfgang Jeltsch-2]

Am Mittwoch, 1. Juli 2009 16:59 schrieb Edward Kmett:
> Bikeshedding: Would it be better to put the definition for +> (or better
> yet <>) in the dictionary for Monoid with a circular definition for
> mappend? That way new code defining Monoid instances can avoid ever having
> to even mention mappend.

+1

Best wishes,
Wolfgang
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Alexander Dunlap]

On Tue, Jun 30, 2009 at 5:37 PM, Bryan O'Sullivan<[hidden email]> wrote:

> Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339
>
> From the ticket:
>
> This proposal was, I think, originally suggested by Jules Bean. The idea is
> to add two functions to the Data.Monoid module, (+>) and (<+), corresponding
> to different uses of mappend. These should not be methods of the Monoid
> typeclass, but top-level functions.
>
> I hope (but slightly doubt) that the visual nature of the two operators
> might help to counter the thought that monoids are just for gluing things
> together.
>
> (+>) :: (Monoid a) => a -> a -> a
> a +> b = a `mappend` b
>
> (<+) :: (Monoid a) => a -> a -> a
> a <+ b = b `mappend` a
>
> infixl 4 +>
> infixl 4 <+
>
> Proposed deadline: two weeks.
>
> If this looks reasonable, I'll attach darcs patches.
>

I (and apparently a lot of other people who commented on that ticket)
would prefer that (++) be generalized instead of introducing a new
operator.

Alex
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Edward A Kmett]

The main concern with generalizing (++) is that it was once generalized -- completely differently! -- for mplus in MonadPlus. So whether Monoid's mappend is the natural generalization of (++) or MonadPlus's mplus is, is not entirely clear. Neither one can completely subsume all of the use-cases of the other.

 

A secondary concern is that neither MonadPlus nor Monoid are in the Prelude, so its generalized form would have to be exported from Data.Monoid with a different type signature breaking any pre-existing code that brought in Data.Monoid unqualified and happened to use lists.

 

I'm less sold by the second concern than the first one, but both make me hesitate.

 

Bryan's/Jules's existing proposal of a new operator avoids both of these snarls.

 

-Edward Kmett

 

On Fri, Jul 17, 2009 at 10:53 AM, Alexander Dunlap <[hidden email]> wrote:

On Tue, Jun 30, 2009 at 5:37 PM, Bryan O'Sullivan<[hidden email]> wrote:

> Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339
>
> From the ticket:
>
> This proposal was, I think, originally suggested by Jules Bean. The idea is
> to add two functions to the Data.Monoid module, (+>) and (<+), corresponding
> to different uses of mappend. These should not be methods of the Monoid
> typeclass, but top-level functions.
>
> I hope (but slightly doubt) that the visual nature of the two operators
> might help to counter the thought that monoids are just for gluing things
> together.
>
> (+>) :: (Monoid a) => a -> a -> a
> a +> b = a `mappend` b
>
> (<+) :: (Monoid a) => a -> a -> a
> a <+ b = b `mappend` a
>
> infixl 4 +>
> infixl 4 <+
>
> Proposed deadline: two weeks.
>
> If this looks reasonable, I'll attach darcs patches.
>

I (and apparently a lot of other people who commented on that ticket)
would prefer that (++) be generalized instead of introducing a new
operator.

Alex

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Wolfgang Jeltsch-2]

Am Freitag, 17. Juli 2009 21:57 schrieb Edward Kmett:
> The main concern with generalizing (++) is that it was once generalized
> -- completely differently! -- for mplus in MonadPlus. So whether Monoid's
> mappend is the natural generalization of (++) or MonadPlus's mplus is, is
> not entirely clear. Neither one can completely subsume all of the use-cases
> of the other.

I hope that in the long run, we will be able to drop Alternative and
MonadPlus. This will be possible once we allow universal quantification in
contexts. Instead of writing (MonadPlus m), we can write (Monad m, forall a.
Monoid (m a)) then. This makes it rather clear that Monoid (mappend) would be
the better generalization of (++). MonadPlus (mplus) is a bit of a hack.

Best wishes,
Wolfgang
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Conor McBride-2]

On 18 Jul 2009, at 10:21, Wolfgang Jeltsch wrote:

> Am Freitag, 17. Juli 2009 21:57 schrieb Edward Kmett:
>> The main concern with generalizing (++) is that it was once  
>> generalized
>> -- completely differently! -- for mplus in MonadPlus. So whether  
>> Monoid's
>> mappend is the natural generalization of (++) or MonadPlus's mplus  
>> is, is
>> not entirely clear. Neither one can completely subsume all of the  
>> use-cases
>> of the other.
>
> I hope that in the long run, we will be able to drop Alternative and
> MonadPlus. This will be possible once we allow universal  
> quantification in
> contexts. Instead of writing (MonadPlus m), we can write (Monad m,  
> forall a.
> Monoid (m a)) then. This makes it rather clear that Monoid (mappend)  
> would be
> the better generalization of (++). MonadPlus (mplus) is a bit of a  
> hack.

Until that joyous day, I'd like to hope we might consider ensuring
that MonadPlus m, Alternative m, and Monoid (m a) functionalities
do at least coincide.

I'm thinking in particular of Maybe, which behaves splendidly as
an implementation of an exception monad, until you start using
foldMap as a control operator.

Cheers

Conor

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Edward A Kmett]

On Sat, Jul 18, 2009 at 6:14 AM, Conor McBride <[hidden email]> wrote:

Until that joyous day, I'd like to hope we might consider ensuring

that MonadPlus m, Alternative m, and Monoid (m a) functionalities
do at least coincide.

I'm thinking in particular of Maybe, which behaves splendidly as
an implementation of an exception monad, until you start using
foldMap as a control operator.

Yeah, the Monoid instance for Maybe is somewhat unfortunate. 

I can see where they were going as Maybe does provide the natural extension of a semigroup into a monoid by adding a unit element, but it doesn't have a Semigroup class to build on, and so has to require Monoid and in the end you get a definition that conflicts with the MonadPlus/Alternative instances for Maybe, and only really helps if you have broken Monoid instances around that are secretly just Semigroups.

-Edward Kmett

 

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Conor McBride-2]

Hi Edward

On 18 Jul 2009, at 14:23, Edward Kmett wrote:

>
> Yeah, the Monoid instance for Maybe is somewhat unfortunate.
>
> I can see where they were going as Maybe does provide the natural  
> extension of a semigroup into a monoid by adding a unit element, but  
> it doesn't have a Semigroup class to build on, and so has to require  
> Monoid and in the end you get a definition that conflicts with the  
> MonadPlus/Alternative instances for Maybe, and only really helps if  
> you have broken Monoid instances around that are secretly just  
> Semigroups.

Exactly.

Types should mean more than mere data representations. The
current Monoid instance is inconsistent with the broad
interpretation of Maybe as a monad for exceptional computations.
An isomorphic data representation can and should be used to
attach a unit element to a semigroup,

Data structures are data with structure.

All the best

Conor

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Ross Paterson]

On Tue, Jun 30, 2009 at 02:37:51PM -0700, Bryan O'Sullivan wrote:

> Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339
>
> From the ticket:
>
> This proposal was, I think, originally suggested by Jules Bean. The
> idea is to add two functions to the Data.Monoid module, (+>) and (<+),
> corresponding to different uses of mappend. These should not be methods
> of the Monoid typeclass, but top-level functions.
>
> I hope (but slightly doubt) that the visual nature of the two operators
> might help to counter the thought that monoids are just for gluing
> things together.

This proposal seems to have got stuck.  Everyone wants an infix operator,
but we can't agree what it should be.

I prefer using a new operator instead of generalizing ++ (or +, *, &&
or ||), because I think that a monoid operation is so abstract that it
needs a name that doesn't suggest one of the special cases.  (I like <>)
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Samuel Bronson]

On Thu, Sep 17, 2009 at 9:37 AM, Ross Paterson <[hidden email]> wrote:

> This proposal seems to have got stuck.  Everyone wants an infix operator,
> but we can't agree what it should be.
>
> I prefer using a new operator instead of generalizing ++ (or +, *, &&
> or ||), because I think that a monoid operation is so abstract that it
> needs a name that doesn't suggest one of the special cases.  (I like <>)

I agree. <> really seems to fit well, even if it *does* reinforce the
idea that Monoid is for gluing things together -- which, you know, it
really is rather good for.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Edward A Kmett]

I also really like <>.

On Thu, Sep 17, 2009 at 4:52 PM, Samuel Bronson <[hidden email]> wrote:

On Thu, Sep 17, 2009 at 9:37 AM, Ross Paterson <[hidden email]> wrote:

> This proposal seems to have got stuck.  Everyone wants an infix operator,
> but we can't agree what it should be.
>
> I prefer using a new operator instead of generalizing ++ (or +, *, &&
> or ||), because I think that a monoid operation is so abstract that it
> needs a name that doesn't suggest one of the special cases.  (I like <>)

I agree. <> really seems to fit well, even if it *does* reinforce the
idea that Monoid is for gluing things together -- which, you know, it
really is rather good for.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Nicolas Pouillard-2]

Excerpts from Edward Kmett's message of Fri Sep 18 00:11:12 +0200 2009:
> I also really like <>.

I'm also in favor of <>

>
> On Thu, Sep 17, 2009 at 4:52 PM, Samuel Bronson <[hidden email]> wrote:
>
> > On Thu, Sep 17, 2009 at 9:37 AM, Ross Paterson <[hidden email]>
> > wrote:
> >
> > > This proposal seems to have got stuck.  Everyone wants an infix operator,
> > > but we can't agree what it should be.
> > >
> > > I prefer using a new operator instead of generalizing ++ (or +, *, &&
> > > or ||), because I think that a monoid operation is so abstract that it
> > > needs a name that doesn't suggest one of the special cases.  (I like <>)
> >
> > I agree. <> really seems to fit well, even if it *does* reinforce the
> > idea that Monoid is for gluing things together -- which, you know, it
> > really is rather good for.
> > _______________________________________________
> > Libraries mailing list
> > [hidden email]
> > http://www.haskell.org/mailman/listinfo/libraries
> >

--
Nicolas Pouillard
http://nicolaspouillard.fr
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Krasimir Angelov-2]

On 9/17/09, Ross Paterson <[hidden email]> wrote:
> I prefer using a new operator instead of generalizing ++ (or +, *, &&
> or ||), because I think that a monoid operation is so abstract that it
> needs a name that doesn't suggest one of the special cases.  (I like <>)

<> collides with the same operator defined in Text.PrettyPrint. Please
don't add operator that collides with something else that is already
in the standard libraries. The operators looks very ugly when they are
quantified. We should save at least some very often used functions and
operators from collision.

Krasimir
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Malcolm Wallace]

> <> collides with the same operator defined in Text.PrettyPrint. Please
> don't add operator that collides with something else that is already
> in the standard libraries.

Is it possible that the pretty-printing <> is in fact just another  
instance of the Monoidal mappend?

Regards,
     Malcolm

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Heinrich Apfelmus]

Nicolas Pouillard wrote:
> Excerpts from Edward Kmett's message of Fri Sep 18 00:11:12 +0200 2009:
>> I also really like <>.
>
> I'm also in favor of <>

mappend me to the list of people who prefer  <> .


Regards,
apfelmus

--
http://apfelmus.nfshost.com

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Jean-Philippe Bernardy]

> Is it possible that the pretty-printing <> is in fact just another instance
> of the Monoidal mappend?

Yes.

(<>) :: Doc -> Doc -> Doc Source
Beside. <> is associative, with identity empty.

http://haskell.org/ghc/docs/latest/html/libraries/pretty/Text-PrettyPrint-HughesPJ.html#v%3A<>

-- JP
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Krasimir Angelov-2]

Ok. Then this proposal should be accompanied with the proposal to
generalize Text.PrettyPrint.<>.


On 9/18/09, Jean-Philippe Bernardy <[hidden email]> wrote:

> > Is it possible that the pretty-printing <> is in fact just another instance
> > of the Monoidal mappend?
>
> Yes.
>
> (<>) :: Doc -> Doc -> Doc       Source
> Beside. <> is associative, with identity empty.
>
> http://haskell.org/ghc/docs/latest/html/libraries/pretty/Text-PrettyPrint-HughesPJ.html#v%3A<>
>
> -- JP
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Duncan Coutts]

On Thu, 2009-09-17 at 14:37 +0100, Ross Paterson wrote:

> This proposal seems to have got stuck.  Everyone wants an infix operator,
> but we can't agree what it should be.
>
> I prefer using a new operator instead of generalizing ++ (or +, *, &&
> or ||), because I think that a monoid operation is so abstract that it
> needs a name that doesn't suggest one of the special cases.  (I like <>)

Nice. For some reason I much prefer a symbol like <> to one like +>.

I want to say that it's because it looks symmetric, though of course
mappend, ++ are associative not symmetric, so it's not a very good
argument. But I still like it! :-)

So I guess we should adjust the proposal, or make a new one.
      * Suggest the name <> (which so far seems to have popular support)
      * Get rid of the suggestion for a reverse mappend operator
      * As Krasimir says, include in the proposal that we would deal
        with the existing libraries that use a local <> for their
        mappend operator (at least Text.PrettyPrint).

One thing we've not mentioned much is operator precedence. Existing
uses:
  infixr 5 Data.Sequence.><
  infixl 6 Text.PrettyPrint.<>
Existing proposal about (+>)
  infixl 4 +>

Duncan

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

[Edward A Kmett]

I'ved chewed on the associativity and precedence issue for <> a little bit. Here are my thoughts.

infixl 6 <> would match the precedence of +, which is nice on paper, and how I happen to implement (+) in Data.Monoid.Sugar in the monoids library. I now believe that it is not quite right.

On paper infixr vs. infixl is basically irrelevant because the result is monoidal, but in practice infixr tends to work better for a lot of real world monoids we care about like list appending. Take a look at the behavior of ((... ++ b) ++ c) vs (a ++ (b ++ ...) for a compelling justification for why infixr is probably better in practice for the poster child of the monoid lineup.

Ross's infixr 5 >< in Data.Sequence is the same precedence and fixity as ++, which also seems like a good answer at first, but infixr 5 <> would change the behavior of programs that use Text.PrettyPrint.HughesPJ, which relies on the fixity of <> and <+> being higher than $$ and $+$ which are infixl 5.

The original proposed infixr/l 4 is low enough that you couldn't even mix the use of <> with the various comparators from Eq and Ord, and it exacerbates all of the above issues -- by inverting the precedence of $$ and <> -- so I think it should be off the table. For similar reasons I don't like lowering the fixity off $$ and $+$ in HughesPJ to 4 to permit infixr 5 <>.

So, in light of all of that, it would seem that the most compatible general change would be to set:

infixr 6 <>

and to change the associativity of <+> in Text.PrettyPrint.HughesPJ to match, so that they can be intermixed. Version 3.0 of the HughesPJ combinators, released back in 1997 has fixed any performance regression that would be caused by changing the associativity. I hope everyone will have upgraded by now. ;)

This binds slightly tighter than ++, but retains the same asymptotic performance, works with == <=, etc. and only requires the minor associativity tweak to HughesPJ, which should be allowed just fine under the pretty printer combinator laws, so exxisting HughesPJ code should continue to run just fine, and other existing code wouldn't be using the new operator, so shouldn't require any tweaks.

-Edward Kmett

On Fri, Sep 18, 2009 at 7:18 AM, Duncan Coutts <[hidden email]> wrote:

On Thu, 2009-09-17 at 14:37 +0100, Ross Paterson wrote:

> This proposal seems to have got stuck.  Everyone wants an infix operator,
> but we can't agree what it should be.
>
> I prefer using a new operator instead of generalizing ++ (or +, *, &&
> or ||), because I think that a monoid operation is so abstract that it
> needs a name that doesn't suggest one of the special cases.  (I like <>)

Nice. For some reason I much prefer a symbol like <> to one like +>.

I want to say that it's because it looks symmetric, though of course
mappend, ++ are associative not symmetric, so it's not a very good
argument. But I still like it! :-)

So I guess we should adjust the proposal, or make a new one.
     * Suggest the name <> (which so far seems to have popular support)
     * Get rid of the suggestion for a reverse mappend operator
     * As Krasimir says, include in the proposal that we would deal
       with the existing libraries that use a local <> for their
       mappend operator (at least Text.PrettyPrint).

One thing we've not mentioned much is operator precedence. Existing
uses:
 infixr 5 Data.Sequence.><
 infixl 6 Text.PrettyPrint.<>
Existing proposal about (+>)
 infixl 4 +>

Duncan

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries