Add an equality macro

[jackfirth]

This is a draft PR I'm leaving up as a reference. It implements a hypothetical equality: macro for specifying what components of a class are relevant when comparing its instances for equality. This code:

class Foo(a, b, c):
  equality:
    a
    b
    c

Expands into this, roughly:

class Foo(a, b, c):
  implements Equatable

  override method equals(other):
    (other is_a Foo)
      && (a == other.a)
      && (b == other.b)
      && (c == other.c)

  override method hashCode():
    let code = 1000003
    let code = 31 * code + a.hashCode()
    let code = 31 * code + b.hashCode()
    let code = 31 * code + c.hashCode()
    code

You can pass arbitrary expressions into equality, not just fields, so this works:

class TwoElementIntSet(a :: Integer, b :: Integer):
  equality:
    min(a, b)
    max(a, b)

I'm drafting this PR for reference in future discussions. I'm not sure this is the way to go, but I did want to make this code available. Consider it a proof of concept.

[hashim-hivery]

Are the a b c on separate lines, a list? If not, would they be nicer in a list? Then they can be in one line

class Foo(a, b, c):
  equality: [a, b, c]

[AlexKnauth]

class Foo(a, b, c):
  equality:
    a
    b
    c

is an equivalent tree to

class Foo(a, b, c):
  equality: a; b; c

[mflatt]

Ok if I change $$ to $& (so this code would need to be updated)?

I think $& connects better to a splicing & in repetitions. That is, $& is a combination of an escape and a splice.

[jackfirth]

Yup, fine by me. I like $& better too.

[mflatt]

And now it's just $. Unlike S-expressions, a group or a list of terms doesn't correspond to a term, so $ can just infer splicing.

[jackfirth]

Oh nice, that's even better

[Lazerbeak12345]

What are the magic numbers here doing?

More specifically; why these numbers?

[AlexKnauth]

It would be good to replace the magic numbers in the hash-code method with a call to a hash-code-combine function similar to hash-code-combine in racket/src/cs/rumble/hash-code.ss.

[jackfirth]

For the 31 constant, see this stackoverflow post. For the 1000003 constant, see this one. I just copied what @AutoValue does since it seemed fine in practice. I'm guessing the reason for picking a large starting constant is to avoid hash codes for small record types being biased to small-ish positive integers.

[sorawee]

Effective Java uses 1000003 in the AutoValue section without using 31 and 1000003 is used as a multiplier. On the other hand, the hashCode recipe section uses 31 without using 1000003. Using both 1000003 and 31 with 1000003 as the initial value is probably fine, but seems unnecessary.

While it might be the case that 1000003 and 31 work, I really dislike how Effective Java says "trust me, just do it and it will be fine" without giving any justification. The inconsistency (using 1000003 in a place and 31 in another place) is also baffling.

I agree with @AlexKnauth that exposing and calling hash-code-combine would be better.

[Lazerbeak12345]

I looked into as many edge cases that came to mind without actually running this, and aside from recommendation to make use of a pre-existing hash method (preventing code duplication and reducing magic number use), I can't see any other issues.

We need to be sure to document that the other value is first getting passed through (_ -: PrivateForEquals) before getting the properties, and everything that entails. But that's for once we actually start writing docs. Unsure if docs would belong in this pr.

[AlexKnauth]

For hash-code-combine, I've made a PR to racket here: racket/racket#4546

[AlexKnauth]

Some updates for recur and hash-code-combine: #274