Type checking of values

[bergmanngabor]

The following expressions are OK according to the current type checker:

    "asd" == count find classesOfTeacher(T2,_SC2);

    Student.schoolClass.courses.school(S,count find studentOfSchool(_,_));

I suggest type inference and the type checker should work for any value, not just variables. Apart from variables, this includes:

• constant literals
• computation values, i.e.
  • aggregation values (currently count only)
  • eval (once it is implemented)

[okrosa]

I pushed in a first commit which handles the two cases mentioned by Gábor:

• Compare constraints (equality and inequality as well)
• PathExpression constraints

However literals can be an input in normal find-neg find constraints as well: pattern Good(X) { EClass(X); } pattern Bad(X) = { EClass(X); find Good(10); } I'll extend the type validation with this as well. I think there are no more problematic constraints.

[bergmanngabor]

"the two cases mentioned by Gábor" I did not mention these two cases in the original bug report (although the specific examples do use such constraints), but rather the following:

• constant literals
• computation values, i.e.
  • aggregation values (currently count only)
  • eval (once it is implemented)

"literals can be an input in normal find-neg find constraints " and count find. And count find embedded in count find. And count find embedded in count find embedded in path expression. And so on.

I believe the real problem is that while variables had type inference, other kinds of value expressions did not, even though they are interchangeable in every kind of constraint. I think this is the thing that needs to be fixed.

[okrosa]

Sorry if I wasn't clear.

• Of couse the literals and computation values handled together. If we introduce the eval the whole type inference should be extended only at one place in the codebase.
• The xtext type provider only works on JVMIdentifiableElements, which our Variable is, but the various ValueReferences are not. If you think about extending the whole functionality onto these as well, this seems to be a much harder problem. Not to mention that I would suggest a reassign to @ujhelyiz .
• However handling the problematic cases with validators seems to be an easier option. I don't see the point to work more on this issue, and I don't really see what plus features could we get with the type infering approach. But correct me if I'm wrong.

[istvanrath]

@okrosa please commit everything (tests) and mark as resolved

[istvanrath]

@okrosa please cherry pick into maintenance branch

[okrosa]

Cherry pick completed.

[istvanrath]

The validator seems to be working fine, however the error message is a bit puzzling (for Gaben's examples):

The types of the literal/computational values are different: EString, EInt. schoolqueries.eiq   /school.incquery/src/school line: 17 /school.incquery/src/school/schoolqueries.eiq  EMF-IncQuery Problem

Are they really EString and EInt? (I would have expected String and Int).

Note: this is a very minor issue.

[okrosa]

I checked my code, and the last commit for the #354 ticket should have solved this issue as well!

[istvanrath]

Nope, at least it doesn't work in the maintenance branch.

[istvanrath]

And it also doesn't work in master.

[okrosa]

@istvanrath can you give me the example, so I can check the same case? At the moment it should not work in the maintenance branch, but it should in the master. One slight problem that it is quite hard to commit this back to the master, as the #354 ticket is 0.7, not to mention that I refactored the respective class in the 0.7 to finish the #309. Based on that I would leave this issue in the 0.6.9 as is, and rework the message just in the 0.7.

[istvanrath]

I'm using @bergmanngabor 's example from the description of this issue: "asd" == count find classesOfTeacher(T2,_SC2); If you write this inside any of the patterns in the school example, it still gives the EInt, EString error message.

As for the 0.7 vs 0.6.9 question: OK.

[okrosa]

Hmm, I get the following error message now (in master): The types of the literal/computational values are different: java.lang.String, int.

[istvanrath]

OK, after a full clean and rebuild it also works correctly for me.

[okrosa]

Actually it is a small change in 6 places, should I commit it into the maintenance branch?

[istvanrath]

yes

[okrosa]

Ok, should be good in the 0.6.9 as well.

[istvanrath]

Indeed, I verified and it works now. Thanks, closing.