Interactive: Type variables not bound sometimes

[Matt Giuca]

When assigning to a variable, type variables which aren't known at the time of assignment are left unbound. This only affects interactive mode.

Observed behaviour:
?> a = [1,2,3]
?> :t a
a :: Array(t_1)
?> x = array_ref(a, 0)
?> x
1
?> :t x
x :: t_1

Expected behaviour:
?> a = [1,2,3]
?> :t a
a :: Array(Int)
?> x = array_ref(a, 0)
?> x
1
?> :t x
x :: Int

This doesn't seem to cause any invalid type errors. e.g. The variable x is still usable where an Int is required. So this may just be a display issue.

[Matt Giuca (mgiuca)]

From TODO note in the repository:

"Need to store a varset with each variable in interactive mode. Otherwise, type variables lose their names and, critically, their bindings."

This is probably sufficient to fix this bug.

[Matt Giuca (mgiuca)]

Needs to be fixed (this isn't part of the type system refactor; it's a high-priority bug).

[Matt Giuca (mgiuca)]

This bug is more serious than thought (bug #418167 has been marked as a duplicate of this). Certain local variables in interactive mode (whose types contain type variables) may fail to unify with other types, because they do not have a varset (so the merge will not properly rename the variables).

This issue can be fixed by keeping a varset for the local variables in interactive mode.

[Matt Giuca (mgiuca)]

From the Bug #418167 report (the more serious behaviour, which isn't just a display issue):

Observed behaviour:
?> a = [1,2,3]
?> :t a
a :: Array(t_1) # This is caused by bug #41861
?> show(a)
Type error in expression 'show(a)'
        Term: a
        Type: Array(a)
        Expected: a.

Expected behaviour:
?> show(a)
[91, 49, 44, 32, 50, 44, 32, 51, 93]

[Matt Giuca (mgiuca)]

Fixed in trunk r926.