Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: Teaching bottomline, part 3: what should improve.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Dan Grossman <djg@c...>
Subject: Re: Teaching bottomline, part 3: what should improve.

 >>  * Error messages of the type system are somewhat obscure. The reflex
 >> of many students is "OCaml wants it to be of type XXX", rather than 
 >> "there is a contradiction in what I wrote". It would be nice if 
there >> was a way to ask OCaml to display additional information on type
 >> errors.

 > This is a long standing peeve of mine. Lets face it: Ocaml just lies.
 > If it has inferred a type, then finds a contradiction, it should
 > report both the location of the contradication AND all of the source
 > lines that contributed to the inference.

Reporting all of the source lines has been investigated; see

C. Haack and J. B. Wells. Type error slicing in implicitly typed
higher-order languages. Science of Computer Programming, 50(1-
3):189–224, 2004.

My intuition is there are many situations where this gives you too much 
information just as one location gives you too little.

Switching to personal horn-tooting mode, you may be interested in a 
paper we have in PLDI next month where we take a completely different 
approach to presenting Caml type-errors -- we don't report any types at 
all, but rather we report a similar program that does type-check.

See http://www.cs.washington.edu/homes/blerner/seminal.html.  The PLDI 
paper is the place to start.  The prototype implementation may prove 
useful to the very brave of heart, but it's really designed to 
demonstrate the idea.

--Dan