On Sat, 2003-07-26 at 16:14, Warren Harris wrote:

>     (f) Type-checker error messages. When something fails to type check 
> in ocaml, the error messages can be uninformative or confusing. Often 
> times the source of a type constraint is far removed from the location 
> where the problem is reported. Showing the source of the constraint 
> would be very helpful. Also, often times the type conflict that's 
> reported fails to narrow down the conflict sufficiently. It would be 
> very helpful if the expected and actual type expressions were unified in 
> some way to pinpoint the exact discrepancy.

Myself and a handful of other researcher are working on this problem. As
you said, the two incompatible type constraints are often far removed to
one another. In fact, most of the times, the mistake is somewhere in
between, along the statements that connect the two constraints together.

I have a prototype solution for a toy version of ocaml which is embedded
in the Drscheme environment. My code takes an error involving a large
amount of code and break it down into small layer. Ideally, each layer
in each layer is small enough that you can be understand it by itself.

Once I am done building the prototype, I intent to port it to David
Goldber's Dromedary, "A CAML-like dialect of ML that works in the
DrScheme environment." and then to ocaml.
   http://www.cs.utah.edu/~goldberg/


Matthias Neubauer and Peter Thiemann at the Universität Freiburg seem to
have gotten good results on the same problem using a form of data flow
analysis. They will be presenting a paper on the subject at icfp 2003
titled "Discriminative sum types locate the source of type errors"

   http://www.informatik.uni-freiburg.de/~neubauer/papers/icfp03.pdf


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners