Errors with named parameters in function types

[sungshik]

Describe the bug

An error sometimes occurs when a (non-keyword) parameter of a function type has a name. The occurrence of the error seems to depend on whether the type of the parameter is user-defined or builtin.

To Reproduce

Example 1 (succeeds):

rascal>int(list[int])    head1 = int(list[int] xs) { return xs[0]; };
int (list[int]): function(|prompt:///|(26,35,<1,26>,<1,61>))

rascal>int(list[int] xs) head2 = int(list[int] xs) { return xs[0]; };
int (list[int]): function(|prompt:///|(26,35,<1,26>,<1,61>))

rascal>int(list[int] ys) head3 = int(list[int] xs) { return xs[0]; };
int (list[int]): function(|prompt:///|(26,35,<1,26>,<1,61>))

Example 2 (fails):

rascal>alias LIST[&T] = list[&T];
ok

rascal>int(LIST[int])    HEAD1 = int(LIST[int] xs) { return xs[0]; };
int (LIST[int]): function(|prompt:///|(26,35,<1,26>,<1,61>))

rascal>int(LIST[int] xs) HEAD2 = int(LIST[int] xs) { return xs[0]; };
|prompt:///|(18,43,<1,18>,<1,61>): Expected int (LIST[int] xs), but got int (LIST[int])
Advice: |https://www.rascal-mpl.org/docs/Rascal/Errors/CompileTimeErrors/UnexpectedType|
ok

rascal>int(LIST[int] ys) HEAD3 = int(LIST[int] xs) { return xs[0]; };
|prompt:///|(18,43,<1,18>,<1,61>): Expected int (LIST[int] ys), but got int (LIST[int])
Advice: |https://www.rascal-mpl.org/docs/Rascal/Errors/CompileTimeErrors/UnexpectedType|
ok

Expected behavior

1. Either both Examples 1/2 succeed, or both fail
2. When put in a module, the type checker succeeds for all of head1, head2, head3, HEAD1, HEAD2, and HEAD3, so the more detailed expectation would be that both Examples 1/2 succeed (i.e., the name of the argument is not part of the type)

[jurgenvinju]

The subtype conputation in the Interpreter goes through a big forwarding and multiple nesting levels of the "double dispatch" design pattern to resolve all the different cases.

Handling aliases in there is quirky because aliases are type equivalences (and thus have commutativity for subtype unlike the other type constructors).

My hunch would be that aliases were not considered for the variance (co- and contra) of function argument types. At least not in all the right places.

[jurgenvinju]

Thanks for the clear report btw @sungshik