What are the laws for Eq1, Eq2, Ord1, and Ord2?

[David Feuer]

Ah, I think I see what you mean. One option:

class EqFoo1 f where
  liftEqSame :: (a -> a -> Bool)
    -> f a -> f a -> Bool
  -- and/or the more principled
  liftEqOnSame ::
    Eq b => (a -> b) -> f a -> f a -> Bool
class (Functor f, EqFoo1) => EqBar1 where
  liftEqDifferent :: (a -> b -> Bool)
    -> f a -> f b -> Bool
  -- and/or the more principled
  liftEqOnDifferent :: Eq c
    => (a -> c) -> (b -> c) -> f a -> f b -> Bool

This wouldn't be the best for my hypothetical Arr type, but I don't know
that it's an important enough case to worry about.

On Mar 15, 2018 11:55 PM, "Gershom B" <gershomb at gmail.com> wrote:

> On March 15, 2018 at 11:50:45 PM, David Feuer (david.feuer at gmail.com)
> wrote:
>
> For Map and HashMap, yes, Eq2 and Ord2 are the problem. For Set and
> HashSet, Eq1 and Ord1 are trouble.
>
> The advantage of the flexibility is that for a Functor or Bifunctor you
> get an optimization: instead of mapping a function or two over each
> container to give them the same type and then comparing the results, you
> can fuse it all into one operation. Of course, the same thing could also be
> done for each type using rewrite rules, but that's kind of gross.
>
> Right. But it is the possibility of this optimization that breaks things.
> In particular, `Set` is not a functor (and does not permit mapping over
> it), but it _should_ be able to be an instance of Eq1.
>
> -g
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180316/78cbf6ef/attachment.html>