I see it as "morally wrong". It's like a Monad instance that doesn't obey the monad laws. The kind of ticking timebomb strong typing is supposed to protect us against. But that only works if we do our part and don't make non-sense instances. Can your consumer get away with using a Hashable instance? (I.e., for use in unordered-containers). This would be morally correct -- the graph could presumably have a valid Hashable instance. On Fri, Apr 24, 2015 at 6:06 AM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:
What is the validity of defining an Ord instance for types for which mathematically the `compare` function is partially ordered?
Specifically, I have a pull request for fgl [1] to add Ord instances for the graph types (based upon the Ord instances for Data.Map and Data.IntMap, which I believe are themselves partially ordered), and I'm torn as to the soundness of adding these instances. It might be useful in Haskell code (the example given is to use graphs as keys in a Map) but mathematically-speaking it is not possible to compare two arbitrary graphs.
What are people's thoughts on this? What's more important: potential usefulness/practicality or mathematical correctness?
(Of course, the correct answer is to have a function of type a -> a -> Maybe Ordering :p)
[1]: https://github.com/haskell/fgl/pull/11
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe