#13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): I still claim that `groupBy` is by no means special: We have literally tons of functions which expect that some argument, be it implicit or explicit, obeys some laws, and those laws are not enforced by the type (so you can actually write down the type without having a Ph.D. in theoretical CS ;-). Take e.g. `Functor`: We expect that the Functor laws are obeyed by all instances. If they're broken, all odds are off and probably most of the function expecting such an argument do strange things. Non-transitive comparison for `sortBy`? Have fun... etc. etc. Nevertheless, we don't repeat such law-breaking examples all over the library documentation. Do we really know which of the 10 `fooBy` functions do something remotely sensible if they don't get an equivalence/total ordering? I doubt that. Without looking at the implementation I would have a hard time figuring that out. Putting the `notBoth1` example below the 'User-supplied equality (replacing an Eq context)' header and just repeating the equivalence requirement in each function documentation is probably the right thing. Similarly for `Ord`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13593#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler