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