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] '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  <> 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 ??


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