Matching fun M:F/A
Jesper Louis Andersen
Thu Jan 2 13:40:55 CET 2020
On Tue, Dec 31, 2019 at 5:12 PM Pierre Fenoll <pierrefenoll@REDACTED>
Admitting equality and by extension unification on function values is a
dangerous game which you usually don't want to play. The reason is that
equality often has to be tailored to the situation.
Stake #1 in the vampire: Function equality is undecidable. We can't
generally handle this:
F = fun(X) -> X + 3 end,
G = fun(X) -> X + 2 + 1 end,
though an optimizing compiler might decide to turn G into the exact same
byte code instructions as F.
Stake #2 in the vampire: reference equality is not very Erlang-like, but it
gives you *some* equality over the function domain. We tend to test
equality by value only.
Stake #3 in the vampire: sensible languages outright *reject* equality on
certain types. And by extension, not all types can be compared in the usual
Stake #4 in the vampire: you often want to equip several different types of
equality to a type
 Sketch of proof: reduce to a solution to the halting problem. Also see
 Classic Haskell98 has a couple of weaknesses here. If you implement Eq,
then you cannot easily implement another kind of Eq for the same type
unless you newtype-wrap it. It is also prevalent in the Ord class with
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions