[GHC] #13593: Unexpected behavior from Data.List.groupBy
GHC
ghc-devs at haskell.org
Thu Apr 20 18:05:38 UTC 2017
#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
More information about the ghc-tickets
mailing list