Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] inference engine
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: skaller <skaller@o...>
Subject: Re: [Caml-list] inference engine
On Wed, 2003-09-17 at 05:46, skaller wrote:
> On Sun, 2003-09-14 at 19:48, Alain.Frisch@ens.fr wrote:
> > On 14 Sep 2003, skaller wrote:
> 
> > > in particular, in the case like:
> > >
> > > 	let rec f1 (x1:t1):r1 = ..
> > > 	and f2 (x2:t2):r2 = ...
> > > 	and f3 (x2:t3):r3 = ..
> > > 	...
> > > 	and f999 (x999:t999):r999 = ...
> > >
> > > the fact the the constraints t1, r1, t2, t2, ..
> > > are not applied until after the whole recursion
> > > is typed
> > 
> > Again, this is wrong.
> 
> Hmm, well the examples are invented to be like
> actual code I have. So perhaps I'm not understanding
> why I'm getting the false errors sometimes.

Here's an example of what I mean (see below for explanation):
-------------------------------------------------------------------------
ocamlopt.opt  -I src  -pp 'camlp4o
/usr/local/lib/ocaml/site-lib/ulex/pa_ulex.cma' -I
/usr/local/lib/ocaml/site-lib/ulex -c src/flx_ulex.ml
File "lpsrc/flx_ulex.ipk", line 730, characters 24-9479:
This expression has type
  lexer_state =
    < adj : int -> unit; append_comment : string -> unit;
      comment_level : int; decode : (string -> string) -> string ->
string;
      decr_comment : unit; get_absolute : string -> string;
      get_comment : string; get_incdirs : string list;
      get_relative : string -> string;
      get_srcref : Ulexing.lexbuf -> string * int * int * int; inbody :
      unit; incr_comment : unit; is_at_line_start : bool;
      newline : Ulexing.lexbuf -> unit; set_comment : string -> unit;
      set_filename : string -> unit; set_line : int -> unit;
      string_of_srcref : Ulexing.lexbuf -> string >
but is here used with type Ulexing.lexbuf
 --------------------------------------------------

now, this message is quite "wrong". There is in fact no
error in the piece of code mentioned in the message.
The message actually occured previously: here it is:

        let ts = pre_flx_lex buf state in 

In this line of code, the order of the arguments
buf and state are backwards. The inference engine
deduced the types of the arguments, and
*incorrectly* decided this piece of code was correct,
and the rather large (10K character) piece of code which came
later was wrong.

In fact, that piece of code starts off:

	and pre_flx_lex state = lexer 

This is a lexer spec for the ulex package, which after
pre-processing reads:

	and pre_flx_lex state lexbuf = 

In fact, in the mli file:

val pre_flx_lex : 
  lexer_state -> 
  Ulexing.lexbuf -> 
  Flx_parse.token list

the correct interface is given. The .mli file is already
compiled, but it isn't consulted until too late to detect
my intent.

IF the type constraint were entered into the inference
engine first, the actual error would have been detected.
As it is, the source reference of the information used
by the inference engine is lost, so it can't say something
like

	"This expression has type lexer_state,
	but appears to be used here with type Ulexing.lexbuf.
	This was deduced from line xxx chars yyy-zzz"

[Where that's the line number of the place the inference
was made]

I can understand that inferences are incremental, and there 
would be a lot of pain tracking *all* the places the data came
from to make a type inference: I'm not suggesting that.

Instead, I tried to suggest that somehow the constraint
be included as early as possible. Clearly here that is NOT
the case, or the error would have been detected where
it actually occured.

Whilst I'm getting used to this, it is a large downside
for newer Ocaml programmers: C++ programmers for example
are used to really horrible template error messages,
but not *wrong* error messages (although I have to admit
some C++ error diagnostic come rather close to that :(

This isn't a complaint. I was simply trying to suggest
a possible way to improve the error reporting. 


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners