Source compatible Rascal modules should lead to binary compatible .tpl modules.

[jurgenvinju]

@PaulKlint we should figure out a way soon-ish to make source compatible Rascal modules in the standard library also be binary compatible .tpl files. For this particular case we can fix the rascal version dependency in rascal-core and typepal, such that the maven plugin, typepal, and the rascal-core are referring to the same version, but more and more (DSL) components will be compiled against different versions of the standard library and turn out to be incompatible only on the .tpl level while they work fine otherwise.

Originally posted by @jurgenvinju in usethesource/rascal-maven-plugin#13 (comment)

[jurgenvinju]

• This could be a general typepal feature that also seeps through in rascal-core
• I suspect that storing an additional table rel[loc qualifiedName, loc source] in the TModel would help. That way users of an imported declaration can refer to the thing by name, and if multiple overloaded instances exist than the relation is simply one-to-many.
• Such a table also exists in the core M3 model (M3.declarations)
• Generating qualified names after name resolution for a module:
  1. every scope has an id already
  2. every declared item has a role
  3. nested scopes is nested names
  4. |<language>+<roleId>:///scope1/scope2/scope3/itemName| could be a mechanism to map typepal resolved names in scopes to logical source locations.

[PaulKlint]

This has been implemented. The TModel now has an extra field map[loc logical,loc physical] logical2physical to store such a mapping. This map is the only place in the TModel where physical locations to the source code of the current model are stored.