[Proposal] Add default implementation of mappend/mempty in terms of mconcat

Hello, I noticed that the current Monoid class doesn't actually provide default implementations of mappend/mempty in terms of mconcat, even though this is technically very simple:
mempty = mconcat [] mappend a b = mconcat [a, b]
This would be a rather small and non-invasive change that shouldn't break any existing programs. The main downside is that an empty Monoid declaration would produce no warnings, but #7633 gives us the ability to solve this. Discussion period: 2 weeks

I'm not sure how I feel about the proposal, but I'd just like to add that in fact the laws for Monoid can also be expressed in terms of mconcat: mconcat [x] = x mconcat . concat = mconcat . map mconcat (for those who appreciate that sort of thing, these are the laws for mconcat to be a monad algebra for the list monad). On Fri, Jan 24, 2014 at 10:42:41PM +0100, Niklas Haas wrote:
Hello,
I noticed that the current Monoid class doesn't actually provide default implementations of mappend/mempty in terms of mconcat, even though this is technically very simple:
mempty = mconcat [] mappend a b = mconcat [a, b]
This would be a rather small and non-invasive change that shouldn't break any existing programs. The main downside is that an empty Monoid declaration would produce no warnings, but #7633 gives us the ability to solve this.
Discussion period: 2 weeks _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

This seems rather pointless; I’m having trouble coming up with an example where mconcat would be easier or more elegant to implement. Do you have an example?
On 24 Jan 2014, at 22:42, Niklas Haas
Hello,
I noticed that the current Monoid class doesn't actually provide default implementations of mappend/mempty in terms of mconcat, even though this is technically very simple:
mempty = mconcat [] mappend a b = mconcat [a, b]
This would be a rather small and non-invasive change that shouldn't break any existing programs. The main downside is that an empty Monoid declaration would produce no warnings, but #7633 gives us the ability to solve this.
Discussion period: 2 weeks _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Hi, Am Montag, den 27.01.2014, 11:42 +0100 schrieb Sjoerd Visscher:
This seems rather pointless; I’m having trouble coming up with an example where mconcat would be easier or more elegant to implement. Do you have an example?
maybe cases where you implement mconcat for performance reasons anyways (but are there good examples for that?), and then you don’t want to be bothered with the simple cases.... Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata@debian.org

Am 27.01.2014 13:23, schrieb Joachim Breitner:
Hi,
Am Montag, den 27.01.2014, 11:42 +0100 schrieb Sjoerd Visscher:
This seems rather pointless; I’m having trouble coming up with an example where mconcat would be easier or more elegant to implement. Do you have an example?
maybe cases where you implement mconcat for performance reasons anyways (but are there good examples for that?),
I think it is useful to define a custom mconcat in cases where it matters whether it is a left or a right fold.
and then you don’t want to be bothered with the simple cases....

On 27/01/14 12:26, Henning Thielemann wrote:
Am 27.01.2014 13:23, schrieb Joachim Breitner:
Hi,
Am Montag, den 27.01.2014, 11:42 +0100 schrieb Sjoerd Visscher:
This seems rather pointless; I’m having trouble coming up with an example where mconcat would be easier or more elegant to implement. Do you have an example?
maybe cases where you implement mconcat for performance reasons anyways (but are there good examples for that?),
I think it is useful to define a custom mconcat in cases where it matters whether it is a left or a right fold.
and then you don’t want to be bothered with the simple cases....
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
You can still define your own mconcat and not use the default definition. There's no case for this proposal from that aspect. -- Mateusz K.

On Mon, Jan 27, 2014 at 12:32:04PM +0000, Mateusz Kowalczyk wrote:
On 27/01/14 12:26, Henning Thielemann wrote:
Am 27.01.2014 13:23, schrieb Joachim Breitner:
Hi,
Am Montag, den 27.01.2014, 11:42 +0100 schrieb Sjoerd Visscher:
This seems rather pointless; I’m having trouble coming up with an example where mconcat would be easier or more elegant to implement. Do you have an example?
maybe cases where you implement mconcat for performance reasons anyways (but are there good examples for that?),
I think it is useful to define a custom mconcat in cases where it matters whether it is a left or a right fold.
and then you don’t want to be bothered with the simple cases....
You can still define your own mconcat and not use the default definition. There's no case for this proposal from that aspect.
Sure, but if you are going to define your own mconcat for performance reasons, it would then be nice not to *have to* define your own mappend, or mempty. Tom

+1 for the original proposal. These are valid default implementations. Nothing more to say. On 27.01.2014 14:29, Tom Ellis wrote:
On Mon, Jan 27, 2014 at 12:32:04PM +0000, Mateusz Kowalczyk wrote:
On 27/01/14 12:26, Henning Thielemann wrote:
Am 27.01.2014 13:23, schrieb Joachim Breitner:
Hi,
Am Montag, den 27.01.2014, 11:42 +0100 schrieb Sjoerd Visscher:
This seems rather pointless; I’m having trouble coming up with an example where mconcat would be easier or more elegant to implement. Do you have an example?
maybe cases where you implement mconcat for performance reasons anyways (but are there good examples for that?),
I think it is useful to define a custom mconcat in cases where it matters whether it is a left or a right fold.
and then you don’t want to be bothered with the simple cases....
You can still define your own mconcat and not use the default definition. There's no case for this proposal from that aspect.
Sure, but if you are going to define your own mconcat for performance reasons, it would then be nice not to *have to* define your own mappend, or mempty.
Tom _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

On 27/01/14 13:29, Tom Ellis wrote:
On Mon, Jan 27, 2014 at 12:32:04PM +0000, Mateusz Kowalczyk wrote:
On 27/01/14 12:26, Henning Thielemann wrote:
Am 27.01.2014 13:23, schrieb Joachim Breitner:
Hi,
Am Montag, den 27.01.2014, 11:42 +0100 schrieb Sjoerd Visscher:
This seems rather pointless; I’m having trouble coming up with an example where mconcat would be easier or more elegant to implement. Do you have an example?
maybe cases where you implement mconcat for performance reasons anyways (but are there good examples for that?),
I think it is useful to define a custom mconcat in cases where it matters whether it is a left or a right fold.
and then you don’t want to be bothered with the simple cases....
You can still define your own mconcat and not use the default definition. There's no case for this proposal from that aspect.
Sure, but if you are going to define your own mconcat for performance reasons, it would then be nice not to *have to* define your own mappend, or mempty.
Tom _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Oh, sorry, I haven't read the original post and jumped to conclusions. +1 from me -- Mateusz K.
participants (8)
-
Andreas Abel
-
Ben Millwood
-
Henning Thielemann
-
Joachim Breitner
-
Mateusz Kowalczyk
-
Niklas Haas
-
Sjoerd Visscher
-
Tom Ellis