From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 83241BB81 for ; Mon, 28 Nov 2005 01:17:20 +0100 (CET) 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 jAS0HJQo008682 for ; Mon, 28 Nov 2005 01:17:19 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA02332 for ; Mon, 28 Nov 2005 01:17:19 +0100 (MET) Received: from smtp.cegetel.net (217-19-192-73.dti.cegetel.net [217.19.192.73]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jAS0HInQ008677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 28 Nov 2005 01:17:19 +0100 Received: from [192.168.144.128] (80-125-86-59.adslgp.cegetel.net [80.125.86.59]) by smtp.cegetel.net (Postfix) with ESMTP id 30FD859A0F1; Mon, 28 Nov 2005 01:17:17 +0100 (CET) Message-ID: <438A4CAA.6070006@univ-savoie.fr> Date: Mon, 28 Nov 2005 01:17:46 +0100 From: Christophe Raffalli User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: fr, en MIME-Version: 1.0 To: Brian Hurt , caml-list@inria.fr Subject: Obj or not Obj References: <4387ACC9.2040107@motion-twin.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 438A4C8F.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 438A4C8E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; christophe:01 raffalli:01 raffalli:01 univ-savoie:01 intimately:01 garbage:01 segfault:01 canasse:01 ocaml's:01 ocaml:01 ocaml:01 typable:01 coq:01 ocamlyacc:01 typable: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 > > As a general rule, unless you work at INRIA, you should never, ever > use the Obj module. Not only will the code be signifigantly less > readable, it'll also be signifigantly more error prone, especially > obscure, hard to debug unless you are intimately familiar with the > inners of the garbage collector, segfault you program at random times, > boy doesn't this feel like C++ bugs. > As nicolas Canasse already said this is a too strong statement, that should/could be commented by somone else at INRIA (otherwise, make install should not install obj at all ;-). Here are a few reason - using Obj requires the same knowledge as writing C interface ... and C is more obscure that OCaml's code with Obj. For instance, my bindlib library for bound variables would be much more error prone in C .. and by the way what do you think of software distributed as patch for Ocaml like FreshOcaml ... - then Obj is sometimes necessary, typically - when trying to have OCaml accept programs that it thinks wrongly to be not typable (like programs extracted from Coq proof) - when you have an "environment" (list, array, etc ...) that needs to contain variables of various AND unknown type (unkown because you are writing libraries or general tools, this is the case of bindlib, code genarated by ocamlyacc and many others). Moreover, all these programs would be typable using dependent types ... - for all the examples above using C would be stupid ! especially for ocamlyacc ;-) Nevertheless, I almost agree, you should just make sure before using Obj that - you read and learn a lot about the runtime - you can not find another way round, even if it cost a little time Just a small word about one of my bad experiment with Obj about tail rec map ... it is easy to get a tail rec map using Obj to make ocaml's list mutable ... it is just slower that the original map and using roughly the same amount of memory, because every cons cell you gain ... is now in the list of grey val as soon as your list does not fit in the minor heap anymore !! So even writing you own mutable_list type would be as bad ! Explanation: the list of grey val is a list of pointers from the major heap to the minor heap which are created when using mutable data structure and which would break incremental GC if each minor GC did not scan the list of grey val) ... This also does mean that you should know a lot about the runtime when using mutable data structures and caring about performance !! So Obj or not Obj (or mutable or not mutable) is always a hard question that needs time ... but definitely, I think the above sentence is too strong.