Browse thread
partial application warning unreliable?
[
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: | 2005-12-09 (02:15) |
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