Version française
Home     About     Download     Resources     Contact us    
Browse thread
partial application warning unreliable?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques Garrigue <garrigue@m...>
Subject: Re: [Caml-list] partial application warning unreliable?
From: skaller <skaller@users.sourceforge.net>

> AHA. In trying to fill out your problem to a real test case
> for a bug report .. I think I have discovered the problem!
> 
> # class cow = object(self) method moo (s:string)= print_endline s
>   end;;
> class cow : object method moo : string -> unit end
> 
> # let y o = o#moo; 1;;
> val y : < moo : 'a; .. > -> int = <fun>
> 
> And there we have it .. an uncaught partial application!
> 
> The reason is clear .. we don't know the arity of the
> function yet -- we don't even know its type.
> 
> The type of a statement is currently 'a, which is just 
> plain wrong. The correct type is void, however unit
> will catch more errors than 'a.

This behaviour has been known for long.
This is for instance why, in the standard library, List.iter is
explicitly given type
   ('a -> unit) -> 'a list -> unit
rather than the inferred
   ('a -> 'b) -> 'a list -> unit
(which actually it had a long time ago, in Caml Special Light)

The trouble is that any change to this behaviour would not be
principal (from the type inference point of view).
That is, we might choose to instantiate 'a to unit when generalizing
the type of y, but actually #moo might be of type int, which we will
discover later, when applying it. As long as returning non-unit in a
statement grades only a warning, we cannot do that.
So, saying that the type of y above is wrong means that all statements
should be forced by type checking to return unit and nothing else.
This is not the default, but this could indeed be done with
-warn-error S.

Note that, for objects, there was before ocaml 3.05 a warning, turned
on only in -labels mode, that ensured that every method was known
before being called. This would have caught the above error. It is now
commented out :-(

Jacques Garrigue