Twan van Laarhoven
How about:
-- intended for |qualified| import |as Ord|: newtype Dual a = Dual { unDual :: a } deriving Eq
+1 for Dual.
+1 for Dual. The term seems common in lattice theory. I use it myself.
Dual does seem to be the right term, but I suggest using DualOrd or DualOrdering instead. The fact that it can be imported qualified is no reason to confuse people, in many cases the function will not be imported qualified, since conflicts are very unlikely. To me just "dual" does not immediatly suggest a reverse ordering. Consider also: sortBy (comparing `on` Dual . fst) stuff vs. sortBy (comparing `on` DualOrd . fst) stuff In the first version it is not immediatly clear that dual has something to do with the ordering, and not just taking some kind of dual of something in some other way.
I plead to accelerate the already perceptible shift towards more qualified imports, and to treat the unqualified import as the exception. Ord is a particularly good candidate for that, since it is hogging the whole partial-order namespace for the special case of linear orders. In your example, if there is only one occurrence of Dual in a large module, then
sortBy (comparing `on` Ord.Dual . fst) stuff
would be natural. In other places, that module might use ``POrd.Dual''... However, if a module uses only Ord duality, and uses that a lot, then it may become more readable to use an unqualified import (still preferably with an explicit import list) and write
sortBy (comparing `on` Dual . fst) stuff
For this special case, I don't want to force qualified import, but suggest it as standard usage, leaving open the more concise second option. The decision to use ``DualOrd'' takes away the concise option, saves only one character over ``Ord.Dual'', and requires more effort to remember --- why is it not ``OrdDual''?
Also, the record selector should be called getDual{Ord}, in accordance with the monoid wrappers and mtl types.
MTL seems to suggest ``runDual'' ;-) ``get*'' sounds far too imparative for my taste. Wolfram