Equality depends on declared type of operands

[sungshik]

Describe the bug

Equality depends in some cases on the declared type of the operands. This leads to unexpected and asymmetric results.

To Reproduce

The following cases do work as expected:

rascal>value x = 5;
value: 5
rascal>x == 5;
bool: true

rascal>value y = [5, 6, 7];
value: [5,6,7]
rascal>y == [5, 6, 7];
bool: true

rascal>z1 = indexOf;
int (list[&T], &T): function(|std:///List.rsc|(5352,518,<210,0>,<229,1>))
rascal>z1 == indexOf;
bool: true

The following cases don't work as expected (HT: @rodinaarssen):

rascal>value z2 = indexOf;
value: function(|std:///List.rsc|(5352,518,<210,0>,<229,1>))
rascal>z2 == indexOf;
bool: false
rascal>indexOf == z2;
bool: false

rascal>syntax S = "s";
ok
rascal>S ss = (S)`s`;
S: (S) `s`
rascal>value vv = ss;
value: appl(
  prod(
    sort("S"),
    [lit("s")],
    {}),
  [appl(
      prod(
        lit("s"),
        [\char-class([range(115,115)])],
        {}),
      [char(115)])],
  src=|prompt:///|(11,1))
rascal>ss == vv
bool: false
rascal>vv == ss
bool: true

[DavyLandman]

Both functions and parse trees are IExternalValue so it might be related to that.

[jurgenvinju]

Excellent report! Thanks.

This is a tricky part in the Rascal design. The == operator is overloaded on the static type of the operands, and it does do different things for different types. The main reason is to keep == fast and furious in general, but still make more semantic sense for specific types. So on value it does hardcode structural equality with sharing, and it does not coerce any types or ignore aspects of the structure (keyword parameters).

For numbers, all numbers are coerced to rat and real if necessary to make it possible to compare 1 == 1.. This also goes for the comparison operators <, <=, >=, >. However if you compare list[int] to a list[rat] the coercion does not take place, for efficiency reasons. The radcal RAP fixes this by eliminating the need for coercion alltogether.

For functions the == is not the cause of the issue. Every function takes it own static type as part of its identity. There for a function with type value fails to be equal to the same function of type int(int). The runtime values of functions keep their "static type" with them at all times.

The example with the Trees indicates an old bug in tree equality. There is an old piece of code that ignores whitespace and @\loc annotations only in one direction, if both operands of == are a Tree. This asymetric feature has been replaced by the := operator. The == on trees should implement an equivalence relation (and so be at least symmetric), and not ignore any layout or keyword parameters.