From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA11246; Mon, 19 Jul 2004 10:58:31 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 KAA11107 for ; Mon, 19 Jul 2004 10:58:30 +0200 (MET DST) Received: from [128.93.8.158] (macaque.inria.fr [128.93.8.158]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i6J8wUEV018188 for ; Mon, 19 Jul 2004 10:58:30 +0200 Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <20040716164020.GA6263@yquem.inria.fr> References: <20040716.093517.95470327.garrigue@kurims.kyoto-u.ac.jp> <20040716164020.GA6263@yquem.inria.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Damien Doligez Subject: Re: [Caml-list] Unboxing options, was RE: assertions or exceptions? Date: Mon, 19 Jul 2004 10:58:34 +0200 To: caml Caml X-Mailer: Apple Mail (2.618) X-Miltered: at nez-perce with ID 40FB8D36.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; damien:01 damien:01 caml-list:01 unboxing:01 caml's:01 pointers:01 -byte:01 aligned:01 compactor:01 compactor:01 pointers:01 jacques':01 jacques:01 short-lived:01 jacques:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Jul 16, 2004, at 18:40, Xavier Leroy wrote: >>> The idea is just to reserve a sufficiently large memory area to >>> represent every needed (Some (Some ...(Some None) ...)). >> >> Caml's internal pointers are at minimum 4-byte aligned. What about >> using the other "safe" set of trailing bits, "10", to mark options? >> i.e.: >> None = ...0010 (2) >> Some None = ...0110 (6) > > This is very tempting indeed, but the Caml heap compactor already uses > the ...10 encoding to temporarily mark some data during compaction. Unless I am badly mistaken, the compactor already has to deal with such values (as out-of-heap pointers) and has no problem with them. However, this is almost the same as Jacques' description, because you still have to make sure that these special values point to some area of memory where nothing will ever be allocated. Finally, Jacques was not quite right in asserting that most options are short-lived. This is only true if you don't use "option" in your main long-lived data structure. Most seasoned OCaml programmers know it, and sometimes it leads to rather contorted data structures. > As Jacques said, we've toyed with the idea of encoding option types > specially for quite a while, and even prototyped it at some point, but > never got convinced that it was really important to do so. It is still bothering me, at least. -- Damien ------------------- 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