English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
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: 2007-05-23 (14:06)
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