Collect all concrete types of children in typesystem rule
I've got a concept whose type should be the least common supertype of its children. I've already found the method leastCommonSupertypes in the SubtypingManager. The problem is that I can't collect a set of the concrete types of the children. Since these types are calculated after the nodes type I've to use when concrete blocks for each child. But of course my first shot failed:
Is the any way to delay the inference rule so that it is executed after the children's rules?
final set<node<>> childTypes = new hashset<node<>>;
node.child.forEach({~c =>
when concrete (typeof(c) as childType) {
childTypes.add(childType);
}
});
typechecker.getSubtypingManager().leastCommonSupertypes(childTypes, true)
The argument set is always empty when the leastCommonSupertypes method is called. Is the any way to delay the inference rule so that it is executed after the children's rules?
Please sign in to leave a comment.
before the method call? Are there any special sleep methods to decrease the CPU usage by this polling loop?
int counter = node.child.size; final set<node<>> childTypes = new hashset<node<>>; node.child.forEach({~c => when concrete (typeof(c) as childType) { childTypes.add(childType); if (--counter == 0) { typeof(node) :==: typechecker.getSubtypingManager().leastCommonSupertypes(childTypes, true) } } });Alternatively, you could assign fresh type variable to each of the children's types and make the resulting type a supertype of them all. Essentially you would instruct the typechecker to find the same LCS, only without the hassle.
node.child.forEach({~c => typeof(node) :>=: typeof(c); });The second one looks interesting. I haven't already understand all details of the type inference rules. Will this version work if the children's types are not subtypes to each other? For example: There are the three types A, B, C with the type hierarchy
A
/\
B C
and the child nodes b of type B and c of type C. Will the resulting type be inferred to A?
I don't see why not.
I've also recognized that instead of when-concrete blocks I can use type variables. Are there any important advantages for one variant?
As to "when concrete" vs. inequalities: if your typesystem is straightforward and type inference does not rely on the inner structure of types, you should avoid "when concretes". These are necessary when there's a need to inspect some type in order to construct another type. Such as inferring a type of a polymorphic method call from parameters.
I've just another type system related question in this context: How does MPS recognizes if two nodes type nodes matches each other? Is there any way to manipulate this behavior for a concept? In detail I want MPS to ignore the value of a property.
The comparison procedure matches each child and each property. For your task, you may want to explore node attributes as an alternative.