Does TC correctly handle transitive extend?

[PaulKlint]

Consider the following program (inspired by the structure of types::AbstractType):

module experiments::Compiler::Examples::Tst4
extend ParseTree;
public data Symbol = deferred(Symbol givenType);
public bool subtype(Symbol t, Symbol::deferred(Symbol s)) = subtype(t,s); 

The situation is that ParseTree extends Type, and Tst4 extends ParseTree. In addition Tst4 extends the Symbol datatype (defined in ParseTree) and thesubtype function defined in Type and extended in ParseTree.

Looking in the info generated by the type checker, Tst4::subtype has all definitions in Type as alternatives but the definitions in ParseTree are missing. Effect: at runtime ParseTree::subtype cannot be found. Curious detail: adding import Type; to the above module solves the problem.

This feels like a transitivity problem, @mahills what is your analysis?

[mahills]

If I run that and ask for the locations of all the items in the overload set I get this:

|project://StandardLibrary/src/lang/rascal/types/ToTest.rsc|(103,73,<5,0>,<5,73>)
|project://StandardLibrary/src/Type.rsc|(4833,107,<150,0>,<150,107>)
|project://StandardLibrary/src/Type.rsc|(5776,108,<165,0>,<165,108>)
|project://StandardLibrary/src/Type.rsc|(3683,449,<128,0>,<136,74>)
|project://StandardLibrary/src/Type.rsc|(7584,133,<188,0>,<188,133>)
|project://StandardLibrary/src/Type.rsc|(5101,59,<153,0>,<153,59>)
|project://StandardLibrary/src/Type.rsc|(6542,106,<177,0>,<177,106>)
|project://StandardLibrary/src/Type.rsc|(7718,91,<189,0>,<189,91>)
|project://StandardLibrary/src/Type.rsc|(4329,55,<144,0>,<144,55>)
|project://StandardLibrary/src/Type.rsc|(5333,86,<158,0>,<158,86>)
|project://StandardLibrary/src/Type.rsc|(4440,74,<146,0>,<146,74>)
|project://StandardLibrary/src/Type.rsc|(4726,106,<149,0>,<149,106>)
|project://StandardLibrary/src/Type.rsc|(7511,72,<187,0>,<187,72>)
|project://StandardLibrary/src/Type.rsc|(4385,54,<145,0>,<145,54>)
|project://StandardLibrary/src/Type.rsc|(7169,91,<183,0>,<183,91>)
|project://StandardLibrary/src/Type.rsc|(6650,84,<179,0>,<179,84>)
|project://StandardLibrary/src/Type.rsc|(5885,100,<166,0>,<166,100>)
|project://StandardLibrary/src/Type.rsc|(4515,128,<147,0>,<147,128>)
|project://StandardLibrary/src/Type.rsc|(4271,56,<142,0>,<142,56>)
|project://StandardLibrary/src/Type.rsc|(5222,92,<155,0>,<155,92>)
|project://StandardLibrary/src/ParseTree.rsc|(6817,70,<160,0>,<160,70>)
|project://StandardLibrary/src/Type.rsc|(6087,96,<170,0>,<170,96>)
|project://StandardLibrary/src/Type.rsc|(6883,143,<181,0>,<181,143>)
|project://StandardLibrary/src/Type.rsc|(4941,99,<151,0>,<151,99>)
|project://StandardLibrary/src/Type.rsc|(7419,91,<186,0>,<186,91>)
|project://StandardLibrary/src/Type.rsc|(5421,98,<159,0>,<159,98>)
|project://StandardLibrary/src/Type.rsc|(5161,60,<154,0>,<154,60>)
|project://StandardLibrary/src/Type.rsc|(7340,78,<185,0>,<185,78>)
|project://StandardLibrary/src/Type.rsc|(6737,145,<180,0>,<180,145>)
|project://StandardLibrary/src/Type.rsc|(4644,81,<148,0>,<148,81>)
|project://StandardLibrary/src/Type.rsc|(6435,106,<176,0>,<176,106>)
|project://StandardLibrary/src/Type.rsc|(4134,136,<138,0>,<141,40>)
|project://StandardLibrary/src/Type.rsc|(7261,78,<184,0>,<184,78>)
|project://StandardLibrary/src/Type.rsc|(6002,84,<169,0>,<169,84>)
|project://StandardLibrary/src/Type.rsc|(5041,59,<152,0>,<152,59>)
|project://StandardLibrary/src/Type.rsc|(7077,91,<182,0>,<182,91>)

So, the definitions from Type, ParseTree, and the current module (ToTest in my case) all appear to be there.

[PaulKlint]

You are right, functions get various identities assigned, and I misread the list of overloaded functions for subtype. Thanks!

So the problem must be further downstream. The only thing I observe at the moment is that subtype is (correctly) classified as having argument type [list[Symbol], list[Symbol)] or [Symbol, Symbol] or [&T, &U]. ParseTree::subtype has as actual parameters [Symbol::\sort(_), Symbol::\adt("Tree", _)] and maybe something goes wrong when converting the type checker's store into the internal representation of the compiler.

I am going to check this right now.

[PaulKlint]

@mahills I think I have isolated the problem related to extend we are discussing here. The compiler identifies all overloaded functions in the same scope and numbers them sequentially.
However, the definition of ParseTree::subtype, gets a scope 0 assigned by the type checker but I think this should be 53 (the scope number subtype gets assigned in module Type) since ParseTree extends Type.

If there are multiple extends and multiple overloaded definitions of a function across these extends they should all get the same scope assigned I think.

The net effect is that the compiler assigns sequence number 0 to ParseTree::subtype (instead of 31 since there are 30 overloaded versions of subtype in Type) and this leads to a missing function definition at run time.

Does this analysis make sense to you or am I missing something?

[mahills]

This makes sense, but I'll have to look to see what I can do about it. They really are defined in different modules, and extending copies the names into scope but doesn't actually make copies of the underlying items (which is why it doesn't adjust the underlying scope IDs, these refer to the containing item, which is still the module they were declared in).

[PaulKlint]

Ok, then at least the analysis of this issue is established. About its solution:

• I let you ponder wether there is a natural solution for this in the type checker
• If this is not possible I will see what I can do in the compiler to massage the definitions as needed.

[PaulKlint]

It turns out that the changed approach to overloading resolution in the compiler also solves this problem.