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

[Caml-list] 'b is unbound
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ 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

```