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 CAA23607; Fri, 16 Jul 2004 02:35:35 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 CAA22972 for ; Fri, 16 Jul 2004 02:35:33 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i6G0ZUSH010840 for ; Fri, 16 Jul 2004 02:35:32 +0200 Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3p2-20030924/3.7W) with ESMTP id JAA26506; Fri, 16 Jul 2004 09:35:17 +0900 (JST) Date: Fri, 16 Jul 2004 09:35:17 +0900 (JST) Message-Id: <20040716.093517.95470327.garrigue@kurims.kyoto-u.ac.jp> To: j.prevost@gmail.com Cc: bhurt@spnz.org, caml-list@inria.fr Subject: Re: [Caml-list] Unboxing options, was RE: assertions or exceptions? From: Jacques GARRIGUE In-Reply-To: References: X-Mailer: Mew version 4.0.64 on Emacs 21.2 / 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 40F722D3.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 unboxing:01 jacques:01 prevost:01 prevost:01 2004:99 cdt:99 boxing:01 unboxing:01 unboxed:01 unbox:01 furuse:01 wwwfun:01 implemented:01 allocating:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: John Prevost > On Thu, 15 Jul 2004 10:38:14 -0500 (CDT), Brian Hurt wrote: > > One of the problems with returning error conditions instead of throwing > > exceptions is the cost of boxing a 'a option. I'd like to advocate for > > the idea of unboxing 'a options. > > This has been discussed before. The essential problem is this: > > Currently: > > type 'a option is not the same as type 'a option option > Some Some 1 is not the same as Some 1 > Some None is not the same as None > > With unboxed options: > > type 'a option is the same as type 'a option option > Some Some 1 is identical to Some 1 > Some None is identical to None I answer before the discussion goes hairy (it already has.) We know perfectly how to unbox options. This is described for instance in my paper with Jun Furuse on optional arguments. http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/papers/rims-1041.html The idea is just to reserve a sufficiently large memory area to represent every needed (Some (Some ...(Some None) ...)). You don't even need to access this area (it might not be physically mapped.) Then all values of type (t option) are represented either by a pointer to this area, or by the wrapped value itself (if it is not an option.) I believe Xavier implemented this trick once, but this has some small cost for both wrapping and unwrapping (you must check whether the value is a pointer to this area), so that there is no clear advantage compared to allocating a block for each Some. Keep in mind that most options are short-lived, so they will be allocated in the young generation, and disappear with the next GC. Such a pattern has a very low cost: just check the allocation limit once in a while. And of course there is no cost for the None case. Conclusion: this is not worth bothering about, and optional implemented in the current way are efficient enough, thank you. Jacques Garrigue ------------------- 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