Proposal: generalise Monoid's mconcat

Artyom yom at artyom.me
Tue Sep 1 10:41:09 UTC 2015


Look at e.g. the Monoid instance for Text. Without “mconcat = concat” it 
would be much slower.

On 09/01/2015 01:39 PM, Fumiaki Kinoshita wrote:
> -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 <ekmett at gmail.com 
> <mailto:ekmett at gmail.com>>:
>
>     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 <ekmett at gmail.com
>     <mailto:ekmett at gmail.com>> 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
>         <petr.mvd at gmail.com <mailto:petr.mvd at gmail.com>> wrote:
>
>
>
>             2015-08-31 21:00 GMT+02:00 David Feuer
>             <david.feuer at gmail.com <mailto:david.feuer at gmail.com>>:
>
>                 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 at haskell.org <mailto:Libraries at haskell.org>
>             http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
>
>     _______________________________________________
>     Libraries mailing list
>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150901/e36df10b/attachment-0001.html>


More information about the Libraries mailing list