Generic Data.List.partition

[David Feuer]

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
performance.

On Oct 20, 2016 3:41 PM, "evan at evan-borden.com" <
evan at evanrutledgeborden.dreamhosters.com> 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 henning-thielemann.de> wrote:
>
>>
>> On Thu, 20 Oct 2016, evan at evan-borden.com 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: https://github.com/eborden/partition
>>>
>>
>> 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 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/20161020/9afec251/attachment.html>