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
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
