Browse thread
[Caml-list] Using -dtypes output in conjunction with a preprocessor
-
art yerkes
-
Michal Moskal
- art yerkes
- Christophe Raffalli
-
Michal Moskal
[
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: | -- (:) |
| 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 <malekith@pld-linux.org> 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:
"typefoo.ml" 3 64 78 "typefoo.ml" 3 64 99
type(
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 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