Add identity ("kind") to types (for the benefit of generated code and runtime system) about vallang HOT 6 CLOSED

Yes let's stick with ints. We can wire them one-to-one in each implementation subtype of Type, and add an abstract method int getKind() to IExternalType, such that the types in the rascal project can comply.

Since we already have random type generation builtin, we can assert the following contract and test for violations in both the vallang and the rascal project:

Type t1, Type t2: t1.getKind().equals(t2.getKind()) <==> t1.getClass().equals(t2.getClass())

This will help if future new type kind implementations accidentally use the same int identifier.

Note that changing these identifiers in vallang in the future would lead to serious binary incompatibility of any generated Rascal/Java code that runs against this "interface". It's a highly leaky abstraction and therefore extremely volatile.
I will make this clear in code comments. Also I will write tests that assert the exact mapping from type kinds to integers, such that they can not be changed without a failing test.

from vallang.

When we have done this here, the next issue will be to apply the same design in the rascal project for all the subtypes of abstract class RascalType implements IExternalType. Let's wait for this.

@PaulKlint all the grammatical non-terminals are implemented with the same type-kind: NonTerminalType. So there is no difference between sort and opt and iter, etc for the getKind() method. Is that ok? Or should we have different kinds for every kind of non-terminal too?

from vallang.

In org.rascalmpl.library.util.ToplevelType you can see the enum that was used until recently, which is rather coarse.
So NonTerminal is considered as one kind. Of course, the more precise the kinds are the better discrimination we get.
But let's stick to a simple scheme for now.

from vallang.

See private message on slack. We might move this to IValue.getMatchFingerprint for more speed and more encapsulation. That way we can also later add more precise fingerprints for different NonTerminals without breaking other code. Consider adding a possible switch case to all the switches that switch on getKind versus adding cases to only the pattern matching code that would use getMatchFingerprint... it's more stable and more contained. And probably much faster :-)

from vallang.

#210

from vallang.

Closing this, as #210 is merged.

from vallang.