3 ms·

I can understand the business reasons behind it, but it would be much better if these checks were implemented directly in mainstream compilers for the benefit o

I can understand the business reasons behind it, but it would be much better if these checks were implemented directly in mainstream compilers for the benefit of everyone.

brianberns 9y ago
Most (all?) functional programming languages implement structural equality automatically. Referential equality only makes sense when records can be mutated. Immutability eliminates whole categories of errors.
- gizmo686 9y ago
  Haskell does not quite implement it automatically, but does support auto-generating it. Assuming all of of a type's component types support structural equality, a new type can support it by adding "deriving (Eq)" to the type declaration. Ocaml has both structural and referential equality tests automatically. Unfortunately (for C-style programmers), structural equality uses "=", while referential equality uses "==". From the Ocaml doc: >On mutable types such as references, arrays, byte sequences, records with mutable fields and objects with mutable instance variables, e1 == e2 is true if and only if physical modification of e1 also affects e2. On non-mutable types, the behavior of ( == ) is implementation-dependent; however, it is guaranteed that e1 == e2 implies compare e1 e2 = 0.
  - wyager 9y ago
    > Ocaml has both structural and referential equality tests automatically. Yep, and Ocaml equality is a giant pain. As for ==, referential equality is almost never what you want, so it’s (IMO) unwise to expose it except as an unsafe primitive. As for =, OCaml’s “polymorphic”/“structural” equality is usually wrong for any non-trivial data structure, so all the comparison-based standard library are functorized over comparison anyway. Use of polymorphic ‘=‘ is basically banned in the codebase I work on. Haskell’s Eq/Ord typeclasses are vastly easier to use and harder to mess up. I think this particular use case is a more or less unambiguous win for typeclasses.

I can understand the business reasons behind it, but it would be much better if these checks were implemented directly in mainstream compilers for the benefit of everyone.

brianberns 9y ago

Most (all?) functional programming languages implement structural equality automatically. Referential equality only makes sense when records can be mutated. Immutability eliminates whole categories of errors.

gizmo686 9y ago
Haskell does not quite implement it automatically, but does support auto-generating it. Assuming all of of a type's component types support structural equality, a new type can support it by adding "deriving (Eq)" to the type declaration. Ocaml has both structural and referential equality tests automatically. Unfortunately (for C-style programmers), structural equality uses "=", while referential equality uses "==". From the Ocaml doc: >On mutable types such as references, arrays, byte sequences, records with mutable fields and objects with mutable instance variables, e1 == e2 is true if and only if physical modification of e1 also affects e2. On non-mutable types, the behavior of ( == ) is implementation-dependent; however, it is guaranteed that e1 == e2 implies compare e1 e2 = 0.
- wyager 9y ago
  > Ocaml has both structural and referential equality tests automatically. Yep, and Ocaml equality is a giant pain. As for ==, referential equality is almost never what you want, so it’s (IMO) unwise to expose it except as an unsafe primitive. As for =, OCaml’s “polymorphic”/“structural” equality is usually wrong for any non-trivial data structure, so all the comparison-based standard library are functorized over comparison anyway. Use of polymorphic ‘=‘ is basically banned in the codebase I work on. Haskell’s Eq/Ord typeclasses are vastly easier to use and harder to mess up. I think this particular use case is a more or less unambiguous win for typeclasses.