English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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


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