[viatra-dev] Type inferrer status

[Zoltán Ujhelyi <zoltan.ujhelyi@xxxxxxxxxxxxxxxx>]

Hi all,

in order to test the new type inferrer before release, last Friday it was merged into master. In general, it does feel as fast as the old one (but no performance measurements were done), and its results are more precise as it uses a combination of the Java and EMF type system internally, and its rule-based nature is expected to make it easier to extend in the future.

We have manually evaluated the behavior of the new type over various projects, and found a few differences:

 * In case of the UML surrogate queries, the old inferrer was incapable of figuring out that the name parameter of the NamedElementQualifiedName pattern is a string, and inferred object. The new inferrer _correctly_ calculates this type (this resulted in API tools error messages, as the generated API changed here).
 * In an industrial project with the help of Balázs Grill we have identified both issues and further differences (thanks for the help!):
    * In some cases with complex multiple inheritance hierarchies in some patterns it is not possible to automatically select a single type for a variable. The old inferrer did not identify them correctly, and selected one type; the new inferrer detects this case and asks the developer to select one of the possible types (and offers all the valid selections it knows). We manually reviewed these cases, and think, it is correct.
    * We have found an issue with evals (more details later).
    * We have identified problematic cases with the original implementation; new type inferrer test cases were extracted from that, and they were fixed (except the eval issue, see later).
 * We made sure that our other examples, such as CPS still work correctly.

In general, this inferrer works as expected; however, yesterday we have identified an issue related to eval that I see no easy fix for. Consider the following (very artificial) pattern:

pattern t4(n) {
	check(n >  2);
	n == eval(2);
}

In this case, the type of ’n' has to be int (or java.lang.Integer) that cannot be specified in the pattern language (yet, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=399620), so the new type inferrer has to rely on the Xbase inferrer to provide this information from the eval; however, we also have to provide this information to the Xbase inferrer for the check expression. This is problematic because the incoming types of check expressions are set by the JVM model inferrer, at which point the return type of eval is not calculable, thus we see it as java.lang.Object, causing multiple issues for the Xbase expression “n > 2”: the comparison operator is not defined for Objects, and the return type cannot be calculated to be a boolean.

However, at a later stage when the pattern matchers are initialized (using the generic API) or generated, the type of ’n’ is correctly identified as java.lang.Integer, making the error possible to be worked around, e.g. by explicitly casting the type of ’n’ in the check expression as follows:

pattern t4(n) {
	check((n as Integer)> 2);
	n == eval(Integer.parseInt("2"));
}

I see the following ways to continue:

1. Try to defer the input type inferrer to a later stage. There is some support built-in for this (shown by Sebastian Zarnekow at last years XtextCon), but it requires quite a deep dive into the Xbase type inferrer, that is (a) undocumented, (b) very complex. It seems possible to do it, but I cannot even guess how much time is needed for this.
2. We could extend the declaration of eval expressions with an optional or mandatory type specification. This would provide enough information to have everything available, but still requires the specification of Java types in the pattern language that is not supported by our current grammar (and is not entirely trivial to do in a backward compatible fashion).
3. Similarly, we could allow to set up types for pattern parameters, or one-parameter constraints that provides this information.

The support of Java types is already planned for 1.4, and the type inferrer can reliable fix this issues with some explicit type declarations. However, un short term (for the release 1.3), we could:
a) either revert the type inferrer
b) keep it in, and document this issue


What do you think?

Zoli
-- Zoltán Ujhelyi

Eclipse Technologies Expert
IncQueryLabs Ltd.