[Haskell-cafe] Ord for partially ordered sets
k-bx at k-bx.com
Mon Apr 27 08:30:32 UTC 2015
While this is a bit off-topic, I'd like to add my 5 cents that often adding
instances for common type-classes might be "bad" even when it's totally
defined for all values, one example is a Monoid instance for HashMap.
So, I'd say that if you might be in doubt -- it's better to not add
instance at all, since your users have no ability to remove it from their
projects (or redefine).
26 квіт. 2015 04:10 "wren romano" <winterkoninkje at gmail.com> пише:
> On Fri, Apr 24, 2015 at 9:06 AM, Ivan Lazar Miljenovic
> <ivan.miljenovic at gmail.com> wrote:
> > What is the validity of defining an Ord instance for types for which
> > mathematically the `compare` function is partially ordered?
> Defining Ord instances for types which are not totally ordered is *wrong*.
> For example, due to the existence of NaN values, Double/Float are not
> totally ordered and therefore their Ord instances are buggy. In my
> logfloat package I have to explicitly add checks to work around the
> issues introduced by the buggy Ord Double instance. This is why I
> introduced the PartialOrd class, and I'm not the first one to create
> such a class. We really ought to have an official PartialOrd class as
> part of base/Prelude. The only question is whether to use Maybe
> Ordering or a specially defined PartialOrdering type (the latter
> optimizing for space and pointer indirection; the former optimizing
> for reducing code duplication for manipulating the
> Ordering/PartialOrdering types).
> Live well,
> Libraries mailing list
> Libraries at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe