Ord for partially ordered sets

[Kostiantyn Rybnikov]

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,
> ~wren
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150427/6317ef35/attachment.html>