search

ursi / purescript-elmish

this will have its own name eventually
https://github.com/ursi/purescript-package-set
3 stars 0 forks source link

Implement SurelyEq #7

Open Quelklef opened 3 years ago

Quelklef commented 3 years ago

I upgraded the Elmish dependency for Y and am consequently requesting that you replace data RefEq with a class SurelyEq, if possible.

There are two main reasons for this request:

  1. My Msg type has no valid Eq instance. While I can wrap in RefEq, that would require me to go around the codebase adding wraps and unwraps. This is not a great experience for the library user. Using a typeclass would grealy mitigate this grossness. You may offer that I could just define an Eq Msg instance with pointer semantics; in fact, this has been my (temporary) solution. However, this means my Eq instance is invalid and I have to be careful not to use it elsewhere. This leads to the second point...

  2. RefEq is wrong. More specifically, when a type a has structural identity semantics, then we can only get one of the following: (a) the Eq (RefEq a) instance is valid; xor (b) RefEq a is equivalent to a. If we want (a), then a RefEq a has different identity semantics than an a, meaning (b) is false. If we want (b), then a RefEq a has structural identity, meaning that (a) is false.

Proposed solution:

Include the SurelyEq typeclass as defined below, and then replace appropriate Eq instances with SurelyEq.

class SurelyEq a where
  surelyEq :: a -> a -> Boolean  -- false negatives allowed, false positives not

instance surelyEqEq :: Eq a => SurelyEq a where
  surelyEq = eq
ursi commented 3 years ago

After looking at your code. I'm guessing what's forcing you to have an Eq instance is your use of onClick. You should be able to define your own onClick using on "click" that doesn't have that constraint. I think that's probably your best workaround for now.

Let's talk about that new type class on a more ergonomic platform.