You would need to provide an Eq
instance for functional types in order to automatically derive it for a type that contains functions. This is a bit problematic, as function comparison can be understood in many different ways. Think of it; when are two functions equivalent?
- When they are mathematically identical (i.e., for same arguments return same results or crash)
- When they are semantically identical (i.e., for the same arguments return same results, or loop respectively, or crash in identical manner; should they share side effects as well?)
- When they are defined in same place in code
- As above but must have identical closures (this is what Erlang does)
- When they are the same functions (references)
- Never (?)
- ...
This is why functional types don't have Eq
instance shipped. I wouldn't recommend writing one, because this would result with an orphan instance and spread ambiguous semantics with respect to the dilemma above.
What you can do is to manually write an instance for X
if you have some planned semantics of it. Note that you should expect some basic laws to be preserved, like
x == x
– reflexivity
(y == x) == (x == y)
– symmetry
not ((x == y) && (y == z)) || (x == z)
– transitivity
But honestly speaking, I don't think it is a good idea to compare functions in general.