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] about Obj.magic
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-06-01 (16:00)
From: dengping zhu <zhudp@c...>
Subject: Re: [Caml-list] about Obj.magic

Thanks for your help! You are right. I solved it by following your
suggestion. The problem is exactly what you said: ty is abstarct. After
I added the equation ty = ty1 -> ty2 in the signature where ty was
defined, I got rid of 'Obj.magic'.

Now I am wondering why Ocaml compiler makes the type declaration
abstract unless you specify like : 
    type ty = ty1 -> ty2
in the signature, since all the functions are concrete. I took it for
granted that the type (ty) must be concrete. 

I always met some type problems in Ocaml. The common case is as follows:
Suppose I define a module 'Test' (test.ml)
module Test : TEST =
     type ty =
          | Int of int
	  | String of string
	  | Float of float
and define the signature as :
module type TEST =
    type ty

Suppose that type ty is very common among all my modules and I want to
reuse it as following:

let f x =
  match x with
  | Int _ -> 1
  | String _ -> 2
  | Float _ -> 3

where, I want x to has type ty.

In this case, the only method I can find is to open the module 'Test'.
Actually, 'open' is not a good way which I tried to avoid. Because I
don't know what the expenses of 'open' is. Another reason is if I open a
few modules, function overwrite will happen, and it is difficult for me
to find out the origins of all the imported functions.


>The behaviour you describe definitely looks like a bug in the compiler.
>But I couldn't reproduce your problem, so I would need the real code
>(or a simplified version of it) to check whether this is really a bug.
>Another reason might be difference in behaviour between SML and Caml
>modules and functors. In Caml all signatures are opaque.
>To check this try writing
>let x = (f (g) : ty1 -> ty2) a
>If you get an error saying that ty is not compatible with ty1 -> ty2,
>then this probably means that ty is abstract. This may happen if you
>define a signature in which ty appears without the equation ty = ty1
>-> ty2. Adding the equation should solve the problem.
>Hope this helps, but your description is to incomplete to conclude
>Jacques Garrigue

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