From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 850D6BBCA for ; Fri, 29 Feb 2008 02:52:27 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAALXzxkfAXQInh2dsb2JhbACQcAEBAQgKKZ0b X-IronPort-AV: E=Sophos;i="4.25,423,1199660400"; d="scan'208";a="9730377" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 29 Feb 2008 02:52:27 +0100 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m1T1qO1S020555 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 29 Feb 2008 02:52:27 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALXzxkeCNhAB/2dsb2JhbACuSQ X-IronPort-AV: E=Sophos;i="4.25,423,1199660400"; d="scan'208";a="23187608" Received: from kurims.kurims.kyoto-u.ac.jp ([130.54.16.1]) by mail4-smtp-sop.national.inria.fr with ESMTP; 29 Feb 2008 02:52:22 +0100 Received: from localhost (orion [130.54.16.5]) by kurims.kurims.kyoto-u.ac.jp (8.13.8/8.13.8) with ESMTP id m1T1qHFs024884; Fri, 29 Feb 2008 10:52:20 +0900 (JST) Date: Fri, 29 Feb 2008 10:52:12 +0900 (JST) Message-Id: <20080229.105212.169552478.garrigue@math.nagoya-u.ac.jp> To: David.Teller@univ-orleans.fr Cc: caml-list@inria.fr Subject: Re: [Caml-list] Safe Obj.magic container ? From: Jacques Garrigue In-Reply-To: <1204212586.11218.21.camel@Blefuscu> References: <37B36607-9F22-4537-B4DB-1E04348E2B90@inria.fr> <1204212586.11218.21.camel@Blefuscu> X-Mailer: Mew version 4.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 47C76558.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; univ-orleans:01 variants:01 variants:01 non-uniform:01 non-uniform:01 annotations:01 untyped:01 persistant:98 polymorphic:01 polymorphic:01 ints:01 caml-list:01 monomorphic:01 interfaces:01 variant:02 From: David Teller > Interesting. Can I assume that, if my type is boxed (in this case, a > polymorphic variant), I can successfully convert it to Obj.t and back ? Yes : polymorphic variants are either ints or normal blocks, so this should work. This is also true for normal variants. Actually I don't know of any non-uniform representation problem outside of floats. Note however that this problem of non-uniform representation is no the only danger when using Obj.magic imprudently. I recall another problem with functional values. I'm afraid only Xavier could explain that one. If you have only (polymorphic) variants, and if you keep the types monomorphic (i.e. always add complete type annotations to Obj.magic or Obj.obj), things should work properly in the current implementation. Of course you should limit that kind of uses to things like persistant storage or C interfaces, where you have to go through an untyped world anyway, and avoid it at all costs in plain ml programs. Jacques Garrigue