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 C53E9BB94 for ; Sat, 23 Jul 2005 20:37:40 +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 j6NIbeSG010157 for ; Sat, 23 Jul 2005 20:37:40 +0200 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 UAA15997 for ; Sat, 23 Jul 2005 20:37:39 +0200 (MET DST) Received: from us17.unix.fas.harvard.edu (us17.unix.fas.harvard.edu [140.247.35.197]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j6NIbcZq010148; Sat, 23 Jul 2005 20:37:39 +0200 Received: from ls04.fas.harvard.edu (ls04.fas.harvard.edu [140.247.34.104]) by us17.unix.fas.harvard.edu (8.12.11/8.12.11) with ESMTP id j6NIbbJw004339; Sat, 23 Jul 2005 14:37:37 -0400 Received: by ls04.fas.harvard.edu (Postfix, from userid 19885) id AB5C61C066; Sat, 23 Jul 2005 14:37:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ls04.fas.harvard.edu (Postfix) with ESMTP id A4F0624035; Sat, 23 Jul 2005 14:37:37 -0400 (EDT) Date: Sat, 23 Jul 2005 14:37:37 -0400 (EDT) From: Michael Alexander Hamburg To: Xavier Leroy Cc: Thomas Fischbacher , 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at concorde with ID 42E28E74.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 42E28E72.006 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 syntax:01 heap:01 binary:01 heap:01 avoided:01 ocaml:01 compiler:01 invariants:01 arrays:01 debugging:01 bug:01 caml-list:01 beginner's: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 Ouch. I bow to your superior experience. Is there a syntax which makes treatment of options easy? That is, if about every other line of my library is an action on objects from this array, is there a convenient way to use options without cluttering up the code? I can't use your second solution, because the objects in the heap may be difficult and expensive to construct, and may have side effects (for example, in one instance they are handles to processes; in another they are handles to Libevent events). Mike On Sat, 23 Jul 2005, Xavier Leroy wrote: > > I was constructing a binary heap of tuples the other day. After pondering > > these options, I just used Obj.magic 0 as the null value in the array. > > The heap was in a module, so nothing else could see the array, and I could > > prove that the code never accessed the null elements, so the use of > > Obj.magic seemed justified. > > In other terms: > > " I was walking in the city the other day. I saw a syringe lying on > the sidewalk. I stuck the needle in my forearm. That was a classy > neighborhood, so the use of the syringe seemed justified. " > > Sorry for being sarcastic, but I strongly feel that any suggestion > to use Obj functions should be avoided on this list. The OCaml > compiler performs some type-dependent optimizations that can result in > incorrect code (w.r.t. GC invariants) if wrong types are given using > Obj.magic. > > 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. > > A few years ago, I spent one full day debugging a mysterious crash > in code provided by a user, then realized that the problem was exactly > the use of Obj.magic outlined above. I then swore to throw away all > bug reports whose repro case uses Obj. So, you can break the type > system with Obj, but you get to keep the pieces afterwards. > > Coming back to the initial question, I would first warn against > premature optimization: quite possibly the overhead of the "option" > solution is negligible. If not, just ask the user to pass an initial > value of the heap element type to the "create heap" function. > > - Xavier Leroy > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >