[
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: | 2004-05-13 (02:54) |
From: | briand@a... |
Subject: | Re: [Caml-list] 'b is unbound |
>>>>> "Damien" == Damien <Damien.Pous@ens-lyon.fr> writes: Damien> polymorphic methods require to be explicitly typed (this Damien> kind of type inference should lead to the one for system F) After little more investigation I found that the following will work : method op (j:(float, Bigarray.float64_elt, Bigarray.c_layout) Bigarray.Array2.t) f x = Seems very straightforward. However there is one confusing aspect : method op (j:(float, Bigarray.float64, Bigarray.c_layout) Bigarray.Array2.t) f x = error -> Unbound type constructor Bigarray.float64 ? Aha ! float64 in bigarray.mli is not a type but a val. So now my method is no longer polymorphic, right ? So everything makes sense until I go back to my bigarray test file : let a = Bigarray.Array2.create Bigarray.float64 Bigarray.c_layout n n;; is OK. let a = Bigarray.Array2.create Bigarray.float64_elt Bigarray.c_layout n n;; error -> Unbound value Bigarray.float64_elt Then I looked at the definition for create and it finally makes sense. However I would argue that it is also _very_ confusing. Why doesn't create simply take the type, i.e. ..._elt instead of ('a, 'b) kind ?? Brian ------------------- 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