[Caml-list] about Obj.magic

[Caml-list] about Obj.magic

[dengping zhu]

Hi, all, 

When should I use 'Obj.magic'? It is really confusing. Now I am converting
a bunch of code from sml to ocaml. During the process, I want to make
sure that the type of every function keep consistent with the original
one. But I still encountered a lot of problems about the types in ocaml. 
For examples, all my base functions are fine in ocaml. But, sometimes when
I tried to combine a few base functions together in the same way as my
original code, I got a type error. After endless trial, I have to use
'Obj.magic'. In some sense, it is good because I can compile my code
now. On the other hand, things will be worse because it is very difficult
to debug if I use a few 'Obj.magic' in my code. I couldn't find out the
origins of all the runtime errors. 

So, we should be very careful to use 'Obj.magic'. Can somebody tell me
the appropriate situation to use this function?

Thanks a lot!

Dengping 



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

Re: [Caml-list] about Obj.magic

[Jacques Garrigue]

From: dengping zhu <zhudp@cs.bu.edu>

> When should I use 'Obj.magic'?

You shouldn't.

> It is really confusing. Now I am converting
> a bunch of code from sml to ocaml. During the process, I want to make
> sure that the type of every function keep consistent with the original
> one. But I still encountered a lot of problems about the types in ocaml. 
> For examples, all my base functions are fine in ocaml. But, sometimes when
> I tried to combine a few base functions together in the same way as my
> original code, I got a type error.

SML97 and ocaml typing are essentially the same, so you are probably
getting something else wrong.
If you can get the types of the functions you are trying to combine,
and the expression where you get a type error, and the result is not
too big, you may ask advice on this list.

> After endless trial, I have to use 'Obj.magic'. In some sense, it is
> good because I can compile my code now. On the other hand, things
> will be worse because it is very difficult to debug if I use a few
> 'Obj.magic' in my code. I couldn't find out the origins of all the
> runtime errors.

Obj.magic turns off _any_ checking. There is nothing like runtime type
checking.  The first error is a segmentation fault, or worse, an
impredictible program.

> So, we should be very careful to use 'Obj.magic'. Can somebody tell me
> the appropriate situation to use this function?

There are none. It is just there so you can do some stuff without
having to modify the C runtime, supposing that you understand what it
means in terms of machine execution. In particular, to do that you
_must_ know that the input and output types have equivalent
representations, which requires deep knowledge of the compiler.

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

Re: [Caml-list] about Obj.magic

[Daniel de Rauglaudre]

Hi,

On Thu, May 30, 2002 at 05:09:43PM -0400, dengping zhu wrote:

> When should I use 'Obj.magic'? It is really confusing. Now I am
> converting a bunch of code from sml to ocaml. [...]

About conversion from SML into OCaml, I may help: these days, I am
trying to convert a program of 70000 lines of SML into OCaml, using
Camlp4. Please ask me if you want more details.

About examples of use Obj.magic, there are the extensible grammars of
Camlp4, and in particular the EXTEND function. I can explain here if
people are interested. And I know that the OCaml toplevel program uses
it also.

In general, like Jacques Garrigue said, don't use Obj.magic if you are
not *absolutely* sure of what you do.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
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

Re: [Caml-list] about Obj.magic

[Oleg]

On Friday 31 May 2002 12:00 am, Daniel de Rauglaudre wrote:

> these days, I am
> trying to convert a program of 70000 lines of SML into OCaml

I'm curious: what's the motivation for doing this?

Thanks
Oleg
-------------------
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

Re: [Caml-list] about Obj.magic

[Daniel de Rauglaudre]

Hi,

On Fri, May 31, 2002 at 01:37:17AM -0400, Oleg wrote:

> > these days, I am
> > trying to convert a program of 70000 lines of SML into OCaml
> 
> I'm curious: what's the motivation for doing this?

1/ The persons having developped this software consider that the SML
community is less active than the OCaml one and they want to use OCaml
more (they have other programs already written in OCaml).

2/ My personal motivation is experimenting Camlp4 and improving the
conversion SML->OCaml for people who would be interested. I enjoy this
challenge.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
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

Re: [Caml-list] about Obj.magic

[Warp]

> When should I use 'Obj.magic'? It is really confusing. Now I am converting
> a bunch of code from sml to ocaml. During the process, I want to make
> sure that the type of every function keep consistent with the original
> one. But I still encountered a lot of problems about the types in ocaml.
> For examples, all my base functions are fine in ocaml. But, sometimes when
> I tried to combine a few base functions together in the same way as my
> original code, I got a type error. After endless trial, I have to use
> 'Obj.magic'. In some sense, it is good because I can compile my code
> now. On the other hand, things will be worse because it is very difficult
> to debug if I use a few 'Obj.magic' in my code. I couldn't find out the
> origins of all the runtime errors.
>
> So, we should be very careful to use 'Obj.magic'. Can somebody tell me
> the appropriate situation to use this function?

One case can be 'almost-legal' : downcasting an object to its implementation
class if you're sure that it has been previously upcasted to the interface
type class.

ex :

(* MLI file *)

class type intf =
  sig
    method a : unit
  end

val new_intf : intf -> intf

(* ML file *)

class impl parent =
  object
    method a = ....
    method b = ....
  end

let new_intf i = (new impl (Obj.magic i : impl) :> intf) (* upcast impl to
intf in order to hide method 'b' *)

Nicolas Cannasse
www.motion-twin.com


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

Re: [Caml-list] SML->OCaml (was: about Obj.magic)

[Daniel de Rauglaudre]

Hi,

On Fri, May 31, 2002 at 09:56:28AM +0100, Richard Bornat wrote:

> I'm _very_ interested.  I have an SML program (stuck in smlNJ 0.93, 
> because that is/was the only sml running under MacOS) which I'd like 
> to translate to OCaml.  Only 31 000 lines, including comments ...
> 
> You are welcome to use it as data :-)
>
> But seriously, though: do you distribute versions of your translator?

It is already distributed: just type:
    camlp4 pa_sml.cmo pr_o.cmo -impl file.sml

But in the latest distributed version (3.04), it was very incomplete.
The current CVS version is more up-to-date.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
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

Re: [Caml-list] about Obj.magic

[Jacques Garrigue]

From: "Warp" <warplayer@free.fr>

> > So, we should be very careful to use 'Obj.magic'. Can somebody tell me
> > the appropriate situation to use this function?
> 
> One case can be 'almost-legal' : downcasting an object to its implementation
> class if you're sure that it has been previously upcasted to the interface
> type class.
> 
> (* MLI file *)
> 
> class type intf =
>   sig
>     method a : unit
>   end
> 
> val new_intf : intf -> intf
> 
> (* ML file *)
> 
> class impl parent =
>   object
>     method a = ....
>     method b = ....
>   end
> 
> let new_intf i = (new impl (Obj.magic i : impl) :> intf) (* upcast impl to
> intf in order to hide method 'b' *)

And here is how to break your code:

class c = object method a : unit end
let i = new_intf (new c)

No, this is not legal in any way.
You shouldn't use Obj.magic, except if you have a formal proof that it
is correct! This supposes a deep knowledge of the type system.

By the way, here is a simple way to do downcasts, when really needed.

# let tbl : (< >, impl) Hashtbl.t = Hashtbl.create 17
  let register obj = Hashtbl.add tbl (obj :> < >) obj
  let recover obj = Hashtbl.find tbl (obj :> < >) ;;
val tbl : (<  >, impl) Hashtbl.t = <abstr>
val register : impl -> unit = <fun>
val recover : < .. > -> impl = <fun>

If you register all objects of class impl, then you can use recover to
get back their original type. If the class is not impl, you will get
an exception rather than a segmentation fault. No need to do anything
unsafe.

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

Re: [Caml-list] about Obj.magic

[Warp]

> > One case can be 'almost-legal' : downcasting an object to its
implementation
> > class if you're sure that it has been previously upcasted to the
interface
> > type class.
> >
> And here is how to break your code:
>
> class c = object method a : unit end
> let i = new_intf (new c)
>

True.
In fact that sample can't be used if the class also use shadow types which
prevents the user from writing his own class and then making the program
crash.

Nicolas Cannasse

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

Re: [Caml-list] about Obj.magic

[Remi VANICAT]

Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> writes:

> From: "Warp" <warplayer@free.fr>
>
> And here is how to break your code:
>
> class c = object method a : unit end
> let i = new_intf (new c)
>
> No, this is not legal in any way.
> You shouldn't use Obj.magic, except if you have a formal proof that it
> is correct! This supposes a deep knowledge of the type system.
>
> By the way, here is a simple way to do downcasts, when really needed.
>
> # let tbl : (< >, impl) Hashtbl.t = Hashtbl.create 17
>   let register obj = Hashtbl.add tbl (obj :> < >) obj
>   let recover obj = Hashtbl.find tbl (obj :> < >) ;;
> val tbl : (<  >, impl) Hashtbl.t = <abstr>
> val register : impl -> unit = <fun>
> val recover : < .. > -> impl = <fun>
>
> If you register all objects of class impl, then you can use recover to
> get back their original type. If the class is not impl, you will get
> an exception rather than a segmentation fault. No need to do anything
> unsafe.

This is implemented in my hweak library, but using weak Hashtable (and
so an impl object will be freed if there is not any other things that
point to them).

(http://aspellfr.free.fr/)
-- 
Rémi Vanicat
vanicat@labri.u-bordeaux.fr
http://dept-info.labri.u-bordeaux.fr/~vanicat
-------------------
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

Re: [Caml-list] about Obj.magic

[dengping zhu]

Hi, thanks for all you guys. 

After carefully checking my code, I tried to remove Obj.magic from my
code. Anyway, at last I have to keep one which is not the case you guys
mentioned. My code is very simple:

-----------
type ty = ty1 -> ty2   

(* where ty1, ty2 are some types I defined before, ty1 is some type like
g * h, while ty2 likes c * d * e * f. *)


let x = (f (g)) a

-----------
Here, f and g are functions, and the return type of (f (g)) is ty, which
is a function type ty1 -> ty2. While, the type of a is ty1. So, the
return type of (f (g)) a should be ty2. Anyway, every time I get an
error here. The error message is: You applied too many parameters... 

I was very surprised. After I removed a, then it is all right and the
return type is ty. So, I was thinking that the compiler treated ty as an
atomic type, not a function type. Then I have to use 'Obj.magic' here.
Anyway, the result with 'Obj.magic' is correct.

Probablely I was wrong here, but I'd like to get the help from you.

Regards,
Dengping





On Fri, 31 May 2002, Daniel de Rauglaudre wrote:

>Hi,
>
>On Thu, May 30, 2002 at 05:09:43PM -0400, dengping zhu wrote:
>
>> When should I use 'Obj.magic'? It is really confusing. Now I am
>> converting a bunch of code from sml to ocaml. [...]
>
>About conversion from SML into OCaml, I may help: these days, I am
>trying to convert a program of 70000 lines of SML into OCaml, using
>Camlp4. Please ask me if you want more details.
>
>About examples of use Obj.magic, there are the extensible grammars of
>Camlp4, and in particular the EXTEND function. I can explain here if
>people are interested. And I know that the OCaml toplevel program uses
>it also.
>
>In general, like Jacques Garrigue said, don't use Obj.magic if you are
>not *absolutely* sure of what you do.
>
>-- 
>Daniel de RAUGLAUDRE
>daniel.de_rauglaudre@inria.fr
>http://cristal.inria.fr/~ddr/
>-------------------
>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
>

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

Re: [Caml-list] about Obj.magic

[Christophe TROESTLER]

On Fri, 31 May 2002, Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> wrote:
> 
> From: "Warp" <warplayer@free.fr>
> 
> > > So, we should be very careful to use 'Obj.magic'. Can somebody tell me
> > > the appropriate situation to use this function?
> > 
> > One case can be 'almost-legal' : downcasting an object [...]
>
> By the way, here is a simple way to do downcasts, when really
> needed.  [...] No need to do anything unsafe.

Is there any safe way to check whether a "kind : ('a, 'b)
Bigarray.kind" parameter is "float64", "complex64",... or are we bound
to do

  kind  = (Obj.magic float64 : ('a, 'b) Bigarray.kind)

Cheers,
ChriS
-------------------
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

Re: [Caml-list] about Obj.magic

[John D. Barnett]

dengping zhu wrote:

>type ty = ty1 -> ty2   
>
>let x = (f (g)) a
>
>... So, I was thinking that the compiler treated ty as an
>atomic type, not a function type.
>
I'm new to ocaml myself, so I'm only guessing. But it seems you could 
test your idea by removing the type definition for ty, allowing the 
compiler to infer the proper function type.

Just a thought-

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

Re: [Caml-list] about Obj.magic

[Olivier Andrieu]

 Christophe TROESTLER [Friday 31 May 2002] :
 > On Fri, 31 May 2002, Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> wrote:
 > > 
 > > From: "Warp" <warplayer@free.fr>
 > > 
 > > > > So, we should be very careful to use 'Obj.magic'. Can somebody tell me
 > > > > the appropriate situation to use this function?
 > > > 
 > > > One case can be 'almost-legal' : downcasting an object [...]
 > >
 > > By the way, here is a simple way to do downcasts, when really
 > > needed.  [...] No need to do anything unsafe.
 > 
 > Is there any safe way to check whether a "kind : ('a, 'b)
 > Bigarray.kind" parameter is "float64", "complex64",... or are we bound
 > to do
 > 
 >   kind  = (Obj.magic float64 : ('a, 'b) Bigarray.kind)

I'm not sure if that's what you mean but in the CVS version, there are
new functions like Genarray.kind :

  external kind: ('a, 'b, 'c) t -> ('a, 'b) kind = "bigarray_kind"

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

Re: [Caml-list] about Obj.magic

[John Max Skaller]

An 'almost legal' use of Obj.magic is to populate an array with dummy 
values.
For example:

    class Deep  ..
    let a = Array.make 100  (Obj.magic 0 :> Deep) in
    let len_a = ref 0 in

This is roughly as safe as an unsafe array access,
only now the array length is a variable.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




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

Re: [Caml-list] about Obj.magic

[Christophe TROESTLER]

On Fri, 31 May 2002, Olivier Andrieu <oandrieu@nerim.net> wrote:
> 
>  Christophe TROESTLER [Friday 31 May 2002] :
>  > Is there any safe way to check whether a "kind : ('a, 'b)
>  > Bigarray.kind" parameter is "float64", "complex64",... or are we bound
>  > to do
>  >   kind  = (Obj.magic float64 : ('a, 'b) Bigarray.kind)
> 
> I'm not sure if that's what you mean but in the CVS version, there are
> new functions like Genarray.kind :
>   external kind: ('a, 'b, 'c) t -> ('a, 'b) kind = "bigarray_kind"

I mean e.g.,

let create kind =
  if kind  = (Obj.magic float64 : ('a, 'b) Bigarray.kind) then
    ... fun a -> ... something ...
  else
    ... fun a -> ... something else ...

where you have to imagine [a] as being a bigarray of kind [kind].

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

Re: [Caml-list] about Obj.magic

[Jacques Garrigue]

From: dengping zhu <zhudp@cs.bu.edu>

> After carefully checking my code, I tried to remove Obj.magic from my
> code. Anyway, at last I have to keep one which is not the case you guys
> mentioned. My code is very simple:
> 
> -----------
> type ty = ty1 -> ty2   
> 
> (* where ty1, ty2 are some types I defined before, ty1 is some type like
> g * h, while ty2 likes c * d * e * f. *)
> 
> 
> let x = (f (g)) a
> 
> -----------
> Here, f and g are functions, and the return type of (f (g)) is ty, which
> is a function type ty1 -> ty2. While, the type of a is ty1. So, the
> return type of (f (g)) a should be ty2. Anyway, every time I get an
> error here. The error message is: You applied too many
> parameters... 

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
anything.

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

Re: [Caml-list] about Obj.magic

[dengping zhu]

Hi,Jacques,

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 =
  struct
     type ty =
          | Int of int
	  | String of string
	  | Float of float
  end;;
------------------------------
and define the signature as :
-----------------------
module type TEST =
  sig
    type ty
  end;;
-----------------------

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.

Dengping








>
>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
>anything.
>
>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

Re: [Caml-list] about Obj.magic

[Pierre Weis]

> Hi,Jacques,
> 
> 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. 

If you need it to be concrete export it as concrete, i.e. with a
definition.

> 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 =
>   struct
>      type ty =
>           | Int of int
> 	  | String of string
> 	  | Float of float
>   end;;
> ------------------------------
> and define the signature as :
> -----------------------
> module type TEST =
>   sig
>     type ty
>   end;;
> -----------------------

You exported ty as abstract again! If you want to use ty as concrete
export its definition as in

module type TEST =
   sig
     type ty =
        | Int of int
        | String of string
        | Float of float
   end;;

> 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'.


Yes it's a good way to use the Module Test. Alternatively you can
qualify stuff from the module by prefixing identifiers with the name
of the module they belong to.

let f = function
  | Test.Int _ -> 1
  | Test.String _ -> 2
  | Test.Float _ -> 3

> Actually, 'open' is not a good way which I tried to avoid. Because I
> don't know what the expenses of 'open' is.

open cost nothing in terms of runtime execution: it is just a compiler
directive that avoid writing Test. all over the place, if Test is used
everywhere.

For more extensive discussion about ``open'' have a look at the
programming guide lines for Caml

http://pauillac.inria.fr/caml/pgl-eng.html

> Another reason is if I open a few modules, function overwrite will
> happen,

Not overwrite but masquerading, which far less complex and error prone.

> and it is difficult for me to find out the origins of all the
> imported functions.
>  Dengping

You should use emacs tags for that (assuming not every function in
your appli is named f or g) ...

Regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


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

Re: [Caml-list] about Obj.magic

[Pierre Weis]

> An 'almost legal' use of Obj.magic is to populate an array with dummy 
> values.
> For example:
> 
>     class Deep  ..
>     let a = Array.make 100  (Obj.magic 0 :> Deep) in
>     let len_a = ref 0 in
> 
> This is roughly as safe as an unsafe array access,
> only now the array length is a variable.
> 
> -- 
> John Max Skaller, mailto:skaller@ozemail.com.au
> snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
> voice:61-2-9660-0850

I'm afraid that this use is not ``almost legal'' and, on the contrary,
it is strongly discouraged by good programming practice!

However, your example is interesting as a good counterexample: this is
typical of a bad usage of Obj.magic! The program you gave is indeed
wrong, unless you have a proof that all the elements of array ``a''
will be assigned before accessed, and may be also you have an
additional proof that the memory management system of Caml can deal
with the integer "0" as a valid object of the class Deep. Hence, this
occurrence of Obj.magic is unsafe, error prone, and should not be
encouraged.

The rule of thumb for usages of Obj.magic is as Jacques already stated
it: you need a theorem to write Obj.magic. That's the way the Caml
system uses it: we always have a meta theorem that proves that this
very occurence of Obj.magic is safe. Otherwise, the resulting program
has always the same property : one day or another, it gives you Bus
error.

Thank you for your example that will help Caml users.

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


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

Re: [Caml-list] about Obj.magic

[John Max Skaller]

Pierre Weis wrote:

>>An 'almost legal' use of Obj.magic is to populate an array with dummy 
>>values.
>>For example:
>>
>>    class Deep  ..
>>    let a = Array.make 100  (Obj.magic 0 :> Deep) in
>>    let len_a = ref 0 in
>>
>>This is roughly as safe as an unsafe array access,
>>only now the array length is a variable.
>>
>>-- 
>>John Max Skaller, mailto:skaller@ozemail.com.au
>>snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
>>voice:61-2-9660-0850
>>
>
>I'm afraid that this use is not ``almost legal'' and, on the contrary,
>it is strongly discouraged by good programming practice!
>
And I'm sorry too, because it is the only way to achieve the desired effect:
Ocaml could do well with a variable length array in the standard 
library, IMHO.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




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

Re: [Caml-list] about Obj.magic

[Pierre Weis]

Hi Gerard,

> Hum. For me, the most frequent use of Obj.magic is when I do input_value 
> of some
> persistent data, and the corresponding meta theorem seems tough to me, 
> since it
> involves a complicated state reasoning (status of the file system, 
> knowledge that the
> contents of the file was not tampered with since it was created, 
> hopefully with output_value, knowledge that the current type environment 
> is consistent with the one
> that prevailed when I did output_value, etc).

You are right input_value is a dangerous primitive that is roughly
speaking equivalent to Obj.magic, and this is reflected in its type
scheme:

# input_value;;
- : in_channel -> 'a = <fun>

Hence, you should not ``use of Obj.magic is when (you) do
input_value'': you should instead try to tame a bit this (over)
polymorphic type, for instance by defining specialized versions of
input_value and output_value that are statically type related.

To input/output values of type ty, I generally define two functions
input_ty and output_ty defined as a pair of explicitely typed
functions, as in:

let (output_ty : out_channel -> ty -> unit), (input_ty : in_channel -> ty) =
    (fun oc x -> output_value oc x),
    (fun ic -> input_value ic);;

This way, ``the current type environment is consistent with the one
that prevailed when I did output_value'' is automatically verified (at
least, in the most common case where value IOs are performed from
within the same executable).

On the other hand, file tampering seems to me out of reach of a type
system (and a bit similar to moving around .cmo and .cmi files).

> Since I do not have this meta-theorem, it happens to me occasionally
> to get typically Segmentation fault. Without explicit Obj.magic, but
> with its implicit use with input_value, which is to my view its most
> frequent usage, hard to avoid if you want to manage persistent data.
> Gérard

You are perfectly right: value IOs is mandatory to easily manage
persistent data. That's why we need a safe way to do it. I think this
is the last ennoying glitch that remains in the Objective Caml system.

Best regards,
-- 
Pierre Weis

INRIA, Projet Cristal, http://pauillac.inria.fr/~weis
-------------------
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