From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 4AFD3BB94 for ; Sat, 23 Jul 2005 21:19:52 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j6NJJpne012970 for ; Sat, 23 Jul 2005 21:19:51 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA15644 for ; Sat, 23 Jul 2005 21:19:51 +0200 (MET DST) Received: from mail.physik.uni-muenchen.de (mail.physik.uni-muenchen.de [192.54.42.129]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j6NJJoj4016344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 23 Jul 2005 21:19:51 +0200 Received: from localhost (unknown [127.0.0.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id 7220B2000D; Sat, 23 Jul 2005 21:19:50 +0200 (CEST) Received: from mail.physik.uni-muenchen.de ([127.0.0.1]) by localhost (mail.physik.uni-muenchen.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04040-01; Sat, 23 Jul 2005 21:19:48 +0200 (CEST) Received: from mailhost.cip.physik.uni-muenchen.de (kaiser.cip.physik.uni-muenchen.de [141.84.136.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id 64B3A20004; Sat, 23 Jul 2005 21:19:48 +0200 (CEST) Received: from katrin.cip.physik.uni-muenchen.de (katrin.cip.physik.uni-muenchen.de [141.84.136.12]) by mailhost.cip.physik.uni-muenchen.de (Postfix) with ESMTP id EADD326E87; Sat, 23 Jul 2005 21:19:45 +0200 (CEST) Received: by katrin.cip.physik.uni-muenchen.de (Postfix, from userid 3092) id 07F7016BBA; Sat, 23 Jul 2005 21:19:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by katrin.cip.physik.uni-muenchen.de (Postfix) with ESMTP id 0371322135; Sat, 23 Jul 2005 21:19:46 +0200 (CEST) Date: Sat, 23 Jul 2005 21:19:44 +0200 (CEST) From: Thomas Fischbacher To: Xavier Leroy Cc: Michael Alexander Hamburg , caml-list@inria.fr Subject: Re: [Caml-list] How to do this properly with OCaml? In-Reply-To: <42E2393B.5030209@inria.fr> Message-ID: References: <42E2393B.5030209@inria.fr> X-BOFH: Daemons did it MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: amavisd-new at physik.uni-muenchen.de X-Miltered: at concorde with ID 42E29857.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 42E29856.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 arrays:01 ocaml:01 low-level:01 libcamlrun:01 compiler:01 indirection:01 heap:01 heap:01 compiler:01 2005,:98 cip:98 cip:98 lambda:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Sat, 23 Jul 2005, Xavier Leroy wrote: > For instance, the following implementation of "magic" arrays will > eventually cause the GC to crash: > > type 'a t = int array > let get (a: 'a t) i = (Obj.magic a.(i) : 'a) > let set (a: 'a t) i (x: 'a) = a.(i) <- (Obj.magic x : int) > > while the same code with "string" instead of "int" will not. You > don't understand why? Then, don't use Obj.magic. Could this be for precisely the same reason why I used Obj.magic (1,2) where Michael suggested using Obj.magic 0? I suppose Obj.magic () also would not work, right? > Coming back to the initial question, I would first warn against > premature optimization: I do not think this is premature optimization in that particular case. The code I am talking about is quite mature and performed very well for years in its Lisp incarnation - I am just right now transliterating it to OCaml, as I need it there. Another low-level question: it seems to me as if it were a piece of cake to build a C-linkable shared object library that in all respects looks like any old C .so library, but internally uses code that was compiled from OCaml. However, in order to get there, I had to ar x libcamlrun.a and ld a new libcamlbytecode.so shared object from the pieces. It may well be that I just missed something in the documentation due to my own stupidity/ignorance, but so far it seems to me as if this were tremendously useful, but somehow not documented very well. Anyway, as I clearly do appreciate the option to build C shared objects in something better than C, I wonder whether I can rely on being able to do that trick with future versions of the OCaml compiler as well. > quite possibly the overhead of the "option" solution is negligible. For a lot of applications this is indeed right. However, for the particular one I have in mind right now, I am more or less competing with C code, so I am indeed a bit worried about that extra indirection. > If not, just ask the user to pass an initial > value of the heap element type to the "create heap" function. Well, that's also not that beautiful, but at least, it would work. But coming back to: > while the same code with "string" instead of "int" will not. Can I take this as a guarantee that will also hold for later versions of the compiler? Just for my particular private application - not that I would advise or teach anyone to use such a technique, or distribute any code in compiled or source form that makes use of it. -- regards, tf@cip.physik.uni-muenchen.de (o_ Thomas Fischbacher - http://www.cip.physik.uni-muenchen.de/~tf //\ (lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y) V_/_ (if (= x 0) y (g g (- x 1) (* x y)))) n 1)) (Debian GNU)