Generic Data.List.partition

David Feuer david.feuer at
Thu Oct 20 23:56:01 UTC 2016

Wild guessing: This seems fairly likely to relate somehow to the potential
space leak in certain "optimized" compilations of partition (where the GC
can't see and reduce selector application). Your Foldable version may
benefit in some cases by not being inlined and therefore not getting the
problematic optimization. I don't really know for sure. What is clear is
that the GC trick isn't as reliable as one might hope, given its

On Oct 20, 2016 3:41 PM, "evan at" <
evan at> wrote:

> I'm not sure I propose adding it to base either :)
> Relaxing `t` as the output is certainly correct. I'm not sure if there is
> a correct choice between Alternative or Monoid. That would be an indicator
> that a generic function of this form is arbitrarily opinionated.
> On Thu, Oct 20, 2016 at 3:18 PM, Henning Thielemann <
> lemming at> wrote:
>> On Thu, 20 Oct 2016, evan at wrote:
>> I've given the performance hypothesis a test and it seems that a generic
>>> implementation outperforms the list
>>> implementation. I'm not terribly sure why this is the case, but I also
>>> haven't dumped core.
>>> Implementation and bench:
>> I do not propose to add this to 'base', but if you are after a generic
>> implementation why is the input container type the same as the output type
>> (both 't')? Why not using Alternative.<|> instead of Monoid.<> ?
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list