Hole in type system interpreter: Type parameters in keyword fields of type parameterized data-types are not bound by default expressions

[jurgenvinju]

Describe the bug

rascal>data G[&T] = G(&T t, &T s = 1);
ok
rascal>G("hoi")
G[str]: G("hoi") // this should have been `G[value]` because `value` is the lub of `str` and `int`
rascal>G("hoi").s
int: 1 // zap! that is a consequence of not getting G[value] right. It should be `value: 1` 

Thanks to @rodinaarssen for pointing this out.

[jurgenvinju]

This issue spreads to the design of vallang as well:

• default expressions for constructors and ADTs are not a feature of vallang, for a good reason namely that it would expose expression (computation) semantics to vallang which currently is only about data representation
• each default expression introduces a lowerbound for the type parameters introduced/used by the field
• type lowerbounds on type parameters are not a feature of rascal or vallang either, but
• type upperbounds are a feature of both rascal and vallang

Perhaps it would be good investigating the addition of type lowerbounds to Rascal and vallang:

• it would complete the existing functionality in a natural way by adding the dual of upperbounds
• it would allow us to keep separating computing from data representation (rascal from vallang) by computing lowerbounds based on the default expressions in the Rascal level before declaring constructors and data-types on the vallang level.
• however, this has consequences elsewhere in the type system which we should consider before moving on.

[jurgenvinju]

This is a hole for the compiler run-time as well. A concrete constructor with keyword fields that use parametrized types will not compute the proper least upperbound for the ADT's parameters; as a result a X[void] could start producing an int and confuse the run-time type system completely; leading to FactTypeErrors or worse.