Browse thread
Teaching bottomline, part 3: what should improve.
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | skaller <skaller@u...> |
| Subject: | Re: [Caml-list] Teaching bottomline, part 3: what should improve. |
On Wed, 2007-05-23 at 15:36 +0200, Gerd Stolpmann wrote: > > There is certainly a point. The length of type errors depends on your > programming style. It can also depend on the size of the type involved, which is not nearly as much of a stylistic thing. If you have several polymorphic variants types of 20-30 constructors each, recursively included in each other .. you can get errors many hundreds of lines long, involving scores of invented type variables, and for me, when i get such errors, the information in the diagnostic is more or less entirely useless. I use the error location and knowledge of my last change to track down where to add coercions and annotations to help find the error .. I got one a couple of days ago in code generated by dypgen .. and just gave up .. since I didn't write the code and had no idea what the types were (my types were involved too .. the combination was a type about 80 lines long .. :) Ocaml has improved though: today it often gives a nasty message and the kindly tells you which constructor is causing the mismatch. This helps a LOT! -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net