[
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: | 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