Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Using -dtypes output in conjunction with a preprocessor
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: art yerkes <ayerkes@s...>
Subject: Re: [Caml-list] Using -dtypes output in conjunction with a preprocessor
On Fri, 22 Aug 2003 11:05:18 +0200
Michal Moskal <> wrote:

> How about:
> let f x y = foo x y
> and:
> let g x y = 
>   let baz = foo x y in
>   let qux = foo baz baz in
>   x + 1

Yes, I know that it's not always possible for caml to predict the type, but
the user can resolve such a case with a type annotation.  Alternately, I can
write in the 'default' case that leaves the data unmarshalled.  In either
case it's just as much an error to try to have the language guess what types
C++ needs as it would be in C++.  

In addition, I have done several experiments which show that Ocaml does
correctly type polymorphic applications that have no other possible types.

If you examine the -dtypes output for this code fragment, you'll notice that
the expression at character 78 (as recokoned by -dtypes) is correctly typed,
even though the real type is unspecified:

external ___swig___make_point1 : 'a -> 'b -> 'c = "make_point"
let _ = match ___swig___make_point1 3 3 with
    (a,b) -> print_endline ((string_of_int a) ^ "," ^ (string_of_int b))
  | _ -> ()

If it interests you, here is how Ocaml's type inference *actually* works:

"" 3 64 78 "" 3 64 99
  int -> int -> int * int

The reason why Ocaml can do this, in my recokoning is that any other
signature given for this expression would be an error.  As far as I can
tell, Ocaml will always place a concrete type on an unambiguous expression.
Perhaps Mr. Leroy or one of the other gurus can set me straight, however.

My goal is not necessarily any philosophical purity.  I know that some cases
do fail to unify, and I believe thats OK.  What I'm fighting is a basic
disconnect between the notion of a statically typed overloaded application
in C++, and the Ocaml rule that a certain named value has exactly one type.

I've looked at gcaml for this same reason, B.T.W, but since I'm trying to
balance practical with not, I believe that making the most of the standard
Ocaml is best.
"Should array indices start at 0 or 1? My compromise of 0.5 was rejected
 without, I thought, proper consideration."
   - S. Kelly-Bootle

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: