Type inference does not take "count find" into consideration

[istvanrath]

Take the school example for instance:

  pattern teachesMoreClasses(T1:Teacher, T2:Teacher) = {
    N == count find classesOfTeacher(T1,_SC1);
    M == count find classesOfTeacher(T2,_SC2);
    check((N as Integer) > (M as Integer));
  }

Here, the inferred Java type of N and M should be Integer, but now it is Object.

[istvanrath]

I have verified that this works well with the school example so I'm closing this issue.

[okrosa]

Actually this new type inference feature broke 5 testcases in the UnusedVariableValidationTest. I don't know whether Zoli will have the time to fix them before the release, or I should look into it.

2012/9/26 Istvan Rath notifications@github.com

I have verified that this works well with the school example so I'm closing this issue.

— Reply to this email directly or view it on GitHubhttps://github.com/ujhelyiz/EMF-IncQuery/issues/304#issuecomment-8891760.

[istvanrath]

Unfortunately, a related problem is still present:

 pattern teachesMoreClasses(T1:Teacher, T2:Teacher) {
    N == count find classesOfTeacher(T1,_SC1);
    M == count find classesOfTeacher(T2,_SC2);
    check(N > M);
  }

Here, the Teacher type constraint for T1 is necessary, but I think it could be inferred from the count find call and shouldn't be necessary.

[ujhelyiz]

Removing the Teacher type constraint is not that simple (the semantics of the language are designed that the parameter type is equivalent of writing a similar EClass constraint - in this case Teacher(T1)).

In spring, when working with the reference counter validation, if I remember correctly, @bergmanngabor said that a type constraint is required for the network to calculate the possible set of teachers, so the reference counter validator would disallow this omission. I might be wrong, as I see no reason now for this limitation, but the validator is implemented that way.

For this release, I suggest not implementing this additional type inference feature, and validate this outside the 0.6 timeframe.

[bergmanngabor]

@istvanrath I don't have time to write up a detailed analysis here, but the short answer is that I believe you are wrong. We should discuss this later in person to see if you can convince me.

@ujhelyiz just to clarify, the reason for the validation rule is not a Rete limitation, but a semantics problem independent from the engine implementation.

[istvanrath]

@bergmanngabor ok. closing.