There are local minBy/maxBy functions in the implementation that treat
#15921: Data.List.maximumBy uses counter-intuitive ordering -------------------------------------+------------------------------------- Reporter: qqwy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: List | maximumBy minimumBy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by qqwy): the EQ case differently. That does not feel consistent with the "laws for Ord that are expected to hold" (where EQ would always select the first argument) This is what the problem distills do, and what I feel should be changed (instead making the implementations of the `min'` and `max'` local to `minBy/maxBy` align with the behaviour of the public `min` and `max`). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15921#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler