caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@ozemail.com.au>
To: Alain.Frisch@ens.fr
Cc: Caml list <caml-list@inria.fr>
Subject: Re: [Caml-list] inference engine
Date: 22 Sep 2003 02:45:42 +1000	[thread overview]
Message-ID: <1064162741.12854.73.camel@pelican> (raw)
In-Reply-To: <1063741611.14799.3.camel@pelican>

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


  reply	other threads:[~2003-09-21 16:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-13  6:58 skaller
2003-09-13 10:01 ` David Baelde
2003-09-14  4:12   ` skaller
2003-09-14  9:29     ` Remi Vanicat
2003-09-14  9:48     ` Alain.Frisch
2003-09-16 19:46       ` skaller
2003-09-21 16:45         ` skaller [this message]
2003-09-21 20:43           ` Remi Vanicat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1064162741.12854.73.camel@pelican \
    --to=skaller@ozemail.com.au \
    --cc=Alain.Frisch@ens.fr \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).