Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Obj.magic, Obj.t etc.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <xleroy@p...>
Subject: Re: [Caml-list] Obj.magic, Obj.t etc.
Jacques Garrigue writes:
>
> As an interesting aside, I've discovered recently that even Obj.repr
> is dangerous:
>
> # Obj.repr;;
> - : 'a -> Obj.t = <fun>
> # let arr = Array.create 1 (Obj.repr 1.0);;
> val arr : Obj.t array = [|<abstr>|]
> # arr.(0) <- Obj.repr 1;;
> Segmentation fault

Yes, that's a amusing example, but it just confirms the party line
that *any* function from module Obj is dangerous and must not be used
if one has any hope of type safety.

> From a subtyping point of view, this basically means that there cannot
> be any "top" element in the ocaml type system.

Florian Douetteau writes:

> To be fully accurate, it only means that the current implementation
> of the code generator would not support it directly.

Right.  More generally, I have long advocated the exploitation of
properties of the static type system in optimizing data
representations, runtime system operations, and code generation.
The above is just an exploitation of the property of "classic" ML that
an array is always homogeneous (all elements have the same principal
type).

A corollary is that if the type system changes significantly, some of
these optimizations are invalidated.  Introducing a "top" type is one of
these significant changes.  Quite frankly, I see zero practical uses
of a "top" type, so why bother?

> I don't know if the current runtime implementation makes other
> assumptions of the same kind about the lack of subtyping; for
> instance, the gc could avoid marking the content of an array
> starting with an unboxed integer ? Same thing about list cells.

No, these optimizations are not done because 1- non-float arrays have
the same run-time tag as other data structures, e.g. tuples and
records, and 2- an unboxed int can also represent a constant
constructor from a sum or variant type.  

- Xavier Leroy

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