That bar will be particularly hard to exceed in the presence of toList. On Aug 31, 2015 3:00 PM, "David Feuer" wrote:

The theory of mconcat is that it should handle monoids that need to be summed in some special way. I don't know if anyone actually uses it so, however. Still, Reid is right that the circular dependency sets a very high bar. On Aug 31, 2015 2:47 PM, "Reid Barton" wrote:

...

On Mon, Aug 31, 2015 at 1:54 PM, Fermin Reig wrote:

...

We could generalise:

mconcat:: [a] -> a mconcat = foldr mappend memtpy

to:

mconcat:: Foldable t => t a -> a mconcat = foldr mappend memtpy -- even -- mconcat = fold

I don't understand the appeal of generalizing the type of a function when the generalization already exists; but in this case it's not a viable option anyways because mconcat is a class method of Monoid, and the definition of the Foldable class already refers to Monoid. Creating a circular dependency of Monoid on Foldable would be a headache best avoided.

Regards, Reid Barton

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

I'm personally -1 from a base organizational standpoint following Reid's reasoning. This is just me expressing my own personal opinion rather than any official core libraries committee stance at this time. -Edward On Mon, Aug 31, 2015 at 1:19 PM, Petr Pudlák wrote:

2015-08-31 21:00 GMT+02:00 David Feuer :

...

The theory of mconcat is that it should handle monoids that need to be summed in some special way. I don't know if anyone actually uses it so, however. Still, Reid is right that the circular dependency sets a very high bar.

I guess the [a] monoid is a good example where using mconcat can make a difference.

What seems to be an omission is that Dual has no implementation of mconcat. It'd make sense to define 'mconcat = mconcat . reverse' - if the original monoid benefits from a certain order of operations, we should keep the order.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-1 I would rather propose removing mconcat from Monoid. I've never seen mconcat defined. 2015-09-01 17:04 GMT+09:00 Edward Kmett :

To be clear I was referring to the generalization of mconcat, not to Petr's Dual suggestion

That said, I have a very strong issue with the proposed change to Dual's mconcat. The issue with the Dual suggestion is that reverse requires the list to be finite. This means that even if the monoid could be productive before with Dual it can't with that definition.

-Edward

On Tue, Sep 1, 2015 at 12:56 AM, Edward Kmett wrote:

...

I'm personally -1 from a base organizational standpoint following Reid's reasoning.

This is just me expressing my own personal opinion rather than any official core libraries committee stance at this time.

-Edward

On Mon, Aug 31, 2015 at 1:19 PM, Petr Pudlák wrote:

...

2015-08-31 21:00 GMT+02:00 David Feuer :

...

The theory of mconcat is that it should handle monoids that need to be summed in some special way. I don't know if anyone actually uses it so, however. Still, Reid is right that the circular dependency sets a very high bar.

I guess the [a] monoid is a good example where using mconcat can make a difference.

What seems to be an omission is that Dual has no implementation of mconcat. It'd make sense to define 'mconcat = mconcat . reverse' - if the original monoid benefits from a certain order of operations, we should keep the order.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On 1 September 2015 at 20:39, Fumiaki Kinoshita wrote:

-1

I would rather propose removing mconcat from Monoid. I've never seen mconcat defined.

I've seen cases of mappend defined in terms of mconcat, which was defined explicitly. But I'm -1 for the circular dependency issue.

2015-09-01 17:04 GMT+09:00 Edward Kmett :

...

To be clear I was referring to the generalization of mconcat, not to Petr's Dual suggestion

That said, I have a very strong issue with the proposed change to Dual's mconcat. The issue with the Dual suggestion is that reverse requires the list to be finite. This means that even if the monoid could be productive before with Dual it can't with that definition.

-Edward

On Tue, Sep 1, 2015 at 12:56 AM, Edward Kmett wrote:

...

I'm personally -1 from a base organizational standpoint following Reid's reasoning.

This is just me expressing my own personal opinion rather than any official core libraries committee stance at this time.

-Edward

On Mon, Aug 31, 2015 at 1:19 PM, Petr Pudlák wrote:

...

2015-08-31 21:00 GMT+02:00 David Feuer :

...

The theory of mconcat is that it should handle monoids that need to be summed in some special way. I don't know if anyone actually uses it so, however. Still, Reid is right that the circular dependency sets a very high bar.

I guess the [a] monoid is a good example where using mconcat can make a difference.

What seems to be an omission is that Dual has no implementation of mconcat. It'd make sense to define 'mconcat = mconcat . reverse' - if the original monoid benefits from a certain order of operations, we should keep the order.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com