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 XAA15953; Thu, 15 Jul 2004 23:28:34 +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 XAA15739 for ; Thu, 15 Jul 2004 23:28:32 +0200 (MET DST) Received: from herd.plethora.net (herd.plethora.net [205.166.146.1]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i6FLSSEV018243 for ; Thu, 15 Jul 2004 23:28:30 +0200 Received: from bhurt.plethora.net (bhurt.plethora.net [205.166.146.49]) by herd.plethora.net (8.11.6/8.10.1) with ESMTP id i6FLS5i28643; Thu, 15 Jul 2004 16:28:08 -0500 (CDT) Date: Thu, 15 Jul 2004 16:35:16 -0500 (CDT) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: skaller cc: John Prevost , Ocaml Mailing List Subject: Re: [Caml-list] Unboxing options, was RE: assertions or exceptions? In-Reply-To: <1089926230.29648.632.camel@pelican.wigram> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at nez-perce with ID 40F6F6FC.001 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 unboxed:01 compiler:01 compiler:01 ocaml:01 null:01 null:01 assertions:01 compile:02 pointer:03 wrote:03 allocate:03 behavior:03 referencing:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On 16 Jul 2004, skaller wrote: > This is wrong. The representation being suggested is: > > None -> NULL > Some 'a -> pointer to 'a No. Actually, I was suggesting: None -> NULL Some 'a -> 'a which does have this problem. None isn't the problem- it's a constant in both cases. The problem is the Some case- Some(1) needs to allocate a word of memory to hold the 1 in. By the way, ignore my suggestion that the Ocaml compiler stick in a layer of referencing. You can have a 'a option option without the compiler knowing that it's an option option- consider the following bit of code: let unwrap = function | None -> invalid_arg "unwrap" | Some x -> x ;; Or: let pick deflt = function | None -> deflt | Some x -> x ;; Having both boxed and unboxed options would make these functions impossible to compile. So the two options are: 1) Change the existing behavior (possibly with a warning) 2) Introduce a new type Which actually means I'm leaning towards the new type option. -- "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it." - Gene Spafford Brian ------------------- 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