Re: [Caml-list] Type inference problem

[skaller <skaller@users.sourceforge.net>]

On Tue, 2005-11-01 at 21:19 +1300, Jonathan Roewen wrote:
> Ohh, I found it =) If without else, where return type of if is non-unit.
> 
> Is it possible compiler could flag this error a bit better? IE: when
> if returns non-unit, and there's no else?

Ocaml uses some shortcuts because it doesn't distinguish
functional from procedural code.

Felix does. It uses:

	if c1 then e1 [elif c2 then e2 ..] else ee endif

for functional code -- the 'else' is mandatory, and the expressions
e1, e2 .. ee may not be void, and must unify.

Procedural code uses

	if c do 
		... ; ... ; 
	[elif
		... ; ... ;
	..
	]

	[else
		..; .. ; 
	]
	done;

and all the ... ; entries must be (manifestly) of type void.


Now, the problem with your request is that Ocaml is
*deducing* the type of read .. it is in fact unit, so the
condition for reporting an error you state would NOT catch
any error because there isn't one.

On the other hand if you obey a reasonable style rule:

"always annotate the return type of a recursive function"

then Ocaml would have done precisely what you asked for.
Whenever you get a type error you don't understand
*add type annotations* to try to localise the problem.

I would restate your request like this: when the inference
engine reports a type error, it should provide a full traceback
of all parts of the code that lead it to deduce the conflicting
types.

I expect the error message would be hard to read.. and also that
it would greatly complicate the inference engine to actually
keep track of where all the inferences come from -- not sure
on either point.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net