Discussion:
Proposal: Implement minimumOn, maximumOn to mirror sortOn
Add Reply
Gabriel Garcia
2018-10-29 23:32:19 UTC
Reply
Permalink
Hello,

I have a small proposal for review here:
https://phabricator.haskell.org/D5110

I'd like to start the discussion on whether this is a useful/acceptable
addition the core library.

Thanks,
- Gabriel
Edward Kmett
2018-10-29 23:57:34 UTC
Reply
Permalink
I personally have no strong objection here. Yes there is a Fairbairn
threshold argument to be had, but to be honest, we've already let that go
with sortOn, so consistency seems to be the better option.

I'm +1.

-Edward
Post by Gabriel Garcia
Hello,
https://phabricator.haskell.org/D5110
I'd like to start the discussion on whether this is a useful/acceptable
addition the core library.
Thanks,
- Gabriel
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Eric Mertens
2018-10-30 00:09:04 UTC
Reply
Permalink
Having the consistency with `sortOn` seems like a win, but the reason we
have `sortOn` is that the implementation is not completely trivial. It has
to be ever so slightly smart to reuse the projections when sorting.

On the other hand, we have the definitions:

minimumOn = minimumBy . comparing
maximumOn = maximumBy . comparing

It’s not obvious to me that this needs its own name instead of simply
mentioning that `comparing` exists in the haddock documentation for
`minimumBy` and `maximumBy`.

Is it a foregone conclusion that we should maintain consistency with
`minimum` and `maximum` on their result types? I consider these types
mistakes and would have preferred to see `Maybe` involved.

minimumOn :: (Foldable t, Ord b) => (a -> b) -> t a -> Maybe a

I’m not sure why it makes sense to force ourselves into returning an
imprecise exception in the empty list case.

Best regards,
Eric Mertens
Andrew Martin
2018-10-30 12:13:53 UTC
Reply
Permalink
I am -1 on this. These functions are built on top of foldl1. Consequently,
they are partial functions. The constraint on these is rightfully Foldable1
(possibly to be renamed to Semifoldable), which may one day reside in base.
Although we cannot go back in time and prevent the proliferation of partial
functions in base, we can avoid introducing more of them.
Post by Eric Mertens
Having the consistency with `sortOn` seems like a win, but the reason we
have `sortOn` is that the implementation is not completely trivial. It has
to be ever so slightly smart to reuse the projections when sorting.
minimumOn = minimumBy . comparing
maximumOn = maximumBy . comparing
It’s not obvious to me that this needs its own name instead of simply
mentioning that `comparing` exists in the haddock documentation for
`minimumBy` and `maximumBy`.
Is it a foregone conclusion that we should maintain consistency with
`minimum` and `maximum` on their result types? I consider these types
mistakes and would have preferred to see `Maybe` involved.
minimumOn :: (Foldable t, Ord b) => (a -> b) -> t a -> Maybe a
I’m not sure why it makes sense to force ourselves into returning an
imprecise exception in the empty list case.
Best regards,
Eric Mertens
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
Loading...