On 05/09/2012 14:27, Phil Clayton wrote:
I probably spoke a bit too soon here. After more interactive use, it appears that records and tuples can be expanded one level in the types printed back. This can make types much harder to read which may be an issue for those using an interactive session to e.g. inspect expression types by evaluating fragments of code. With the example at the end, 5.4 prints back
val nearest = fn: point -> point list1 -> real * point
which is fairly self-explanatory, whereas r1581 prints back
val nearest = fn: real * real -> (real * real) * (real * real) list -> real * (real
- real)
It really ought to be unwinding any type abbreviations into their right hand sides. Perhaps it is only applying it once rather than repeatedly but that needs to be fixed. The problem with the bug you reported is that it really requires that this be done before unification so fixing the bug necessarily messes up printing. The only way I can see to avoid this is somehow to mark those type abbreviations that discard one or more type variables i.e. where a type variable on the left does not occur on the right, and only force the unwrapping on those. This would have to be inherited by any other type abbreviation that used such a type abbreviation. e.g. type ('a, 'b) t = 'a type ('a, 'b) s = ('a, 'b) t
I can't see a way to fix the bug and still keep the old printing of types with abbreviations. The problem is that the language definition does not consider printing at all.
David