Bug when comparing a nested array

[EugeneDar]

This test crushes because array doesn't have method eq.

[] > nested-arrays-comparing
  assert-that > @
    * (*)
    $.equal-to
      list
        * (*)

[EugeneDar]

@Graur please check

[EugeneDar]

But this tests passed successfully.

[] > nested-arrays-comparing
  assert-that > @
    * (*)
    $.equal-to
      list
        * (list *)

[Graur]

@EugeneDar Looks like expected behavior for me, since array don't have eq object

[EugeneDar]

@yegor256 I think eq is such a fundamental method and we should move it from list to array.

[EugeneDar]

@yegor256 what do you think?

[yegor256]

@EugeneDar if we do this, we will have to re-implement eq in all data primitives and make them understand "types"... I'm not sure it's the right idea. But I'm not against it either.

[EugeneDar]

@yegor256 I think we should listen to more opinions.

[yegor256]

@EugeneDar in the mean time, read this: https://www.yegor256.com/2017/07/11/how-to-redesign-equals.html

[EugeneDar]

@yegor256 I read the article, and I agree that this approach does have benefits. However, if two objects happen to be equal, I want to be sure, not pray that they don't accidentally have the same byte representation. Do you agree with that?

[yegor256]

@EugeneDar it's a philosophical question. Does apple equal to a pear if they both taste the same?

[EugeneDar]

@yegor256 I assume that most programmers using the equals function do not expect to compare their taste. However, I agree that this is more of a philosophical question, for that reason I want to ask a more specific question: "since the language is supposed to be used for static analysis, won't such false positives in the analysis spoil anything?"

[yegor256]

@EugeneDar during the analysis we will transpile source languages to EO. During this tanspilation we will make implicit type information from Java explicitly present in EO:

voif f(int x) {
  return x + 1;
}

This is EO:

[x] > f
  if.
    not.
      x.type_of.eq "int"
    error "Wrong type!"
  x.plus 1 > @

[EugeneDar]

@yegor256 I agree that this is a solution for strictly typed languages. But what to do with non-strictly typed languages? Suppose we critically care about the result of the f function.

def f(request):
    if not_failed(request):
        return "some data"
    else:
        return False

if f("some request") == False:
    print("Failed")
else:
    print("Success")

Can we ensure that such a case works correctly?

[EugeneDar]

@yegor256 I agree.