-1 for the reasons Edward gave.

I think the Monoid instance for Data.Map should be *removed*. Reason: there are at least two meaningful instances. And, the documentation for the current instance is as out spoken as the fish in my non-existent aquarium: "" So, to use the Monoid instance, one has to consult the source code, just to see: instance (Ord k) => Monoid (Map k v) where mempty = empty mappend = union mconcat = unions Fantastic! I could never have though of these cunning implementations myself (sorry, sarcasm, I know). Why not trash these oneliners and free the Monoid instance for whatever the user wants it to do? Of course, I know, pragmatics, we cannot just remove functionality, might break existing code. But at least not silently. Maybe this could be sneaked in with another incompatible change of the Data.Map package? And after five years of having no Monoid instance, one could think of adding the most useful one. Or rather not, but have two newtypes with the respective meaningful implementations. Which we can also have here and now. On 19.05.2014 07:05, Henning Thielemann wrote:

Am 19.05.2014 02:05, schrieb Nick Partridge:

...

instance Monoid v => Monoid (Map k v) where mappend = unionWith mappend

This lets us build up maps with values in a useful Monoid, and mappend them with gusto.

This was discussed two years ago: http://www.haskell.org/pipermail/libraries/2012-April/017743.html

That said, I'd also prefer your instance.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

On May 20, 2014 11:49 AM, "Andreas Abel" wrote:

I think the Monoid instance for Data.Map should be *removed*.

+1 to removing the instance. I'm currently ambivalent towards adding newtypes over Map with Monoid instances. John L.

Reason: there are at least two meaningful instances.

And, the documentation for the current instance is as out spoken as the

fish in my non-existent aquarium:

""

So, to use the Monoid instance, one has to consult the source code, just

to see:

instance (Ord k) => Monoid (Map k v) where mempty = empty mappend = union mconcat = unions

Fantastic! I could never have though of these cunning implementations

myself (sorry, sarcasm, I know).

Why not trash these oneliners and free the Monoid instance for whatever

the user wants it to do?

Of course, I know, pragmatics, we cannot just remove functionality, might

break existing code.

But at least not silently.

Maybe this could be sneaked in with another incompatible change of the

Data.Map package? And after five years of having no Monoid instance, one could think of adding the most useful one. Or rather not, but have two newtypes with the respective meaningful implementations. Which we can also have here and now.

On 19.05.2014 07:05, Henning Thielemann wrote:

...

Am 19.05.2014 02:05, schrieb Nick Partridge:

...

instance Monoid v => Monoid (Map k v) where mappend = unionWith mappend

This lets us build up maps with values in a useful Monoid, and mappend them with gusto.

This was discussed two years ago: http://www.haskell.org/pipermail/libraries/2012-April/017743.html

That said, I'd also prefer your instance.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch.

Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden

andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

...

-----Original message----- From: Andreas Abel Sent: 20 May 2014, 20:49

I think the Monoid instance for Data.Map should be *removed*. -----Original message----- From: Johan Tibell Sent: 20 May 2014, 21:56

-1 to removing the instance. It breaks existing code for negligible benefit: you still have to add newtypes to pick the instance you want.

-1 from me as well. Although I agree that current instance is suboptimal, I do not believe the cost of removing it is justified. After all, the instance is not completely wrong, just not the one people usually expect. Cheers, Milan

-1 to removing the instance, it will just lead to incompatible packages when people declare their own instances to unbreak their code. John

On 21.05.2014 00:10, Joachim Breitner wrote:

Am Dienstag, den 20.05.2014, 17:47 -0400 schrieb Edward Kmett:

...

-1 from me as well, though it is a much softer -1 than on the just breaking everyone silently by changing it.

_Lots_ of users initialize empty maps with mempty

Well, this is another issue, empty should be overloaded via class Empty a where empty :: a but Edward does not like classes without laws.

no problem, let’s replace it with

instance (Ord k) => Monoid (Map k v) where mempty = empty mappend = error "do not use Monoid (Map k v), it is ambiguous"

That should be a compile-time error, please! ;-)

Greetings, Joachim

PS: No, I’m not serious.

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

I find myself rather hesitant to recommend that instantiation of the idea ever since it exploded into a half-dozen packages full of orphan instances, but yes. -Edward On Wed, May 21, 2014 at 6:38 AM, Herbert Valerio Riedel wrote:

On 2014-05-21 at 00:23:44 +0200, Andreas Abel wrote:

...

...

...

_Lots_ of users initialize empty maps with mempty

Well, this is another issue, empty should be overloaded via

class Empty a where empty :: a

Btw, isn't this what

http://hackage.haskell.org/package/data-default

provides? _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Sorry for continuing the off-topic, and for promoting a package of mine: If you only need the class definition, http://hackage.haskell.org/package/data-default-class is a better choice, with no dependencies. If you prefer a single package with all the dependencies (and with additional generics support), my own fork might be useful: http://hackage.haskell.org/package/data-default-generics Although I mirrored the original package dependencies, many of which might actually be unnecessary... (given the generics implementation). Cheers 2014-05-21 15:59 GMT+01:00 Michael Snoyman :

At the risk of veering terribly off-topic... the splitting of data-default into all of those packages caused me a bunch of dependency headaches, most of which I still don't fully comprehend. I miss the good ol' days of a single package.

On Wed, May 21, 2014 at 5:53 PM, Edward Kmett wrote:

...

I find myself rather hesitant to recommend that instantiation of the idea ever since it exploded into a half-dozen packages full of orphan instances, but yes.

-Edward

On Wed, May 21, 2014 at 6:38 AM, Herbert Valerio Riedel wrote:

...

On 2014-05-21 at 00:23:44 +0200, Andreas Abel wrote:

...

...

...

_Lots_ of users initialize empty maps with mempty

Well, this is another issue, empty should be overloaded via

class Empty a where empty :: a

Btw, isn't this what

http://hackage.haskell.org/package/data-default

provides? _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

For what it's worth, I'd find Semigroup v => Monoid (Map k v) both more useful and less surprising than the current unqualified monoid instance for all maps. I say +1 if we can find a good way to deal with the breakage. -0.1 otherwise - it's a significant concern. On Wed, May 21, 2014 at 8:52 AM, Edward Kmett wrote:

There is always the option of folding Default into base, resolving concerns about where you get instances for it and the ensuing package explosion once and for all.

-Edward

On Wed, May 21, 2014 at 11:12 AM, João Cristóvão wrote:

...

Sorry for continuing the off-topic, and for promoting a package of mine:

If you only need the class definition, http://hackage.haskell.org/package/data-default-class is a better choice, with no dependencies.

If you prefer a single package with all the dependencies (and with additional generics support), my own fork might be useful: http://hackage.haskell.org/package/data-default-generics

Although I mirrored the original package dependencies, many of which might actually be unnecessary... (given the generics implementation).

Cheers

2014-05-21 15:59 GMT+01:00 Michael Snoyman :

...

At the risk of veering terribly off-topic... the splitting of data-default into all of those packages caused me a bunch of dependency headaches, most of which I still don't fully comprehend. I miss the good ol' days of a single package.

On Wed, May 21, 2014 at 5:53 PM, Edward Kmett wrote:

...

I find myself rather hesitant to recommend that instantiation of the idea ever since it exploded into a half-dozen packages full of orphan instances, but yes.

-Edward

On Wed, May 21, 2014 at 6:38 AM, Herbert Valerio Riedel wrote:

...

On 2014-05-21 at 00:23:44 +0200, Andreas Abel wrote:

...

>> _Lots_ of users initialize empty maps with mempty

Well, this is another issue, empty should be overloaded via

class Empty a where empty :: a

Btw, isn't this what

http://hackage.haskell.org/package/data-default

provides? _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On 9 Oct 2015, at 08:37, Julian Bean wrote:

Would there be any downside to providing a package with a newtyped Map with all operations ported over? The newtype already exists in semigroups as UnionWith (Map k) v; what is missing is the entire Map API.

Correction. The newtype exists in the package ‘reducers’ not ‘semigroups’.