TC: Provide type info with unexpanded aliases

[PaulKlint]

The type checker provides in the returned configuration definitions for constructors in which aliases have already been expanded. This is fine in most situations but makes it impossible on the compiler-side to do completely faithful type reification and this starts hurting while bootstrapping: then expanded and unexpanded constructor definitions come together and are rejected by the overloading check in the type store.

Now follow:

• An example to illustrate the above.
• More problem cases
• Suggested solutions

Example

module experiments::Compiler::Examples::Tst5
import IO;
alias  INTEGER = int;
data DATA = d(INTEGER n);
value main(list[value] args) {
    iprintln(#DATA);
    return true;
}   

this should print:

type(
  adt(
    "DATA",
    []),
  (adt(
      "DATA",
      []):choice(
      adt(
        "DATA",
        []),
      {cons(
          label(
            "d",
            adt(
              "DATA",
              [])),
          [label(
              "n",
              alias(                    <=== note the alias here
                "INTEGER",
                [],
                int()))],
          [],
          (),
          {})})))

The information provided by the type checker is:

constructor(RSimpleName("d"),cons(adt("DATA",[]),"d",[label("n",int())]),(),0,...))

Note that INTEGER has been expanded to int(). Side note: the type checker does provide alias definitions, but it is very hard to reconstruct their uses in declarations.

More Problem Cases

As far as I can see another problematic cases is an alias inside an alias:

alias  INTEGER = int;
alias MAP = map[INTEGER, str];

where the INTEGER is also expanded away.

In function types aliases are also expanded, I am not yet sure whether that can present any problems, but I suspect that I can construct a problematic example for function types as well.

Possible Solutions

The simplest (and most expensive?) solution would be to duplicate the constructor information (similar for other problem cases) and provide both constructor and constructorWithAliases. Then everything keeps working and only the type reifier in the compiler should start consulting the latter rather than the former.

A more compact option is to only do this in the presence of aliases in a constructor definition. This can also work provided that the constructorWithAliases contains an uid that refers to the expanded version.

[PaulKlint]

An alternative solution could be to this all on the compiler side by analyzing all data and alias declarations. Seems more work than doing it in the typechecker, what do you think @mahills?

[PaulKlint]

I have discussed this issue with @jurgenvinju and he came up with another solution: adapting the interpreter to force expansion of aliases before a constructor is actually introduced in the TypeStore. In this way, aliases can be gradually removed from the PDB and become exclusively a Rascal feature. We will further explore this solution direction.

[mahills]

I think that sounds mostly reasonable, although we do want to make sure that they still display correctly to the user -- it will be confusing if they no longer see the aliases. I actually didn't think I was expanding the versions saved in the configuration (or at least had the unexpanded versions around), so I'll follow up with this on my side as well.

[PaulKlint]

I have solved this issue for now by doing the alias expansion at the PDB level as suggested above.
We may still want to include the unexpanded alias type in the configuration computed by the type checker, but we now have time to make up our minds for what this is precisely needed.

In the meantime I leave this issue open.