Files changed (1)
+to show which type constructors actually contradict, with their source code locations of introduction.
+The idea of this implementation is given by the implementation of Haskell type checker by Lennart Augustsson, demonstrated at his talk at CUFP 2011.
+the programmer is writing a function which returns string... Nothing wrong around the line. Strange!
+This example is so simple that it is easy to see that the problem is the first case which stores an integer to the list,
+but generally speaking, in more complex function definitions we often face more complex instance of this sort of cryptic type errors,
+This is since the ML type inference is actually a simple (but also powerful) constraint solver, using type unification.
+Each syntax construct may introduce some constraints of types to the system, and once the infernece system finds
+the accumulated constraints have no solution, it reports a type error with the source location which added the last constraint.
+But it does not always mean that this position is the place to be fixed. The programmer often feels::
+ The type system tells that this expression of this position has this type and that type at the same time, but they conflict. Wow.
+ But, first of all, I do not even understand why the system thinks this expression should have those types.
+ # GeeeZ! It is not a good example!!! The location should be at the use of variants not at the defs of them!!
+Constructor (::) asks its second argument and return type to be some list. The programmer's feeling should now change::
+Of course this does not pin-point the place to be fixed, but you have more clues which are easier to understand.
+In the typeloc branch, each type expression node (type_expr) has location information of where it is introduced.
+If two type constructors with valid introduction locations are unified, one of them are chosen randomly for the unified type.