From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA11970 for caml-redistribution; Tue, 12 Oct 1999 16:14:19 +0200 (MET DST) 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 KAA01445 for ; Tue, 12 Oct 1999 10:34:49 +0200 (MET DST) Received: from margaux.inria.fr (margaux.inria.fr [128.93.8.2]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id KAA05876; Tue, 12 Oct 1999 10:34:45 +0200 (MET DST) Received: from localhost (riesling.inria.fr [128.93.8.51]) by margaux.inria.fr (8.7.6/8.7.3) with ESMTP id KAA25059; Tue, 12 Oct 1999 10:34:45 +0200 (MET DST) To: chet@watson.ibm.com Cc: caml-list@inria.fr Subject: Option types and O'Labl merger In-Reply-To: Your message of "Sun, 10 Oct 1999 18:38:44 -0400" <199910102238.SAA17988@bismarck.chet.org> References: <199910102238.SAA17988@bismarck.chet.org> X-Mailer: Mew version 1.93 on Emacs 20.4 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19991012103445R.Jacques.Garrigue@inria.fr> Date: Tue, 12 Oct 1999 10:34:45 +0200 From: Jacques Garrigue X-Dispatcher: imput version 980905(IM100) Sender: weis From: chet@watson.ibm.com > Of course, it is problematic that "None" and "Some None" are > indistinguishable. But is it a reason to not have such a facility (as > a storage-cost-free "option" type constructor)? > > I'd like to believe that the answer is "no" -- that the efficiency > values of such a type-constructor outweigh the semantic difficulties. In fact the semantic problem is not that bad. When I implemented O'Labl, I had also the idea that it would be nice to have option types without space (and dereference) cost, particularly since options are used to implement optional arguments. I even went as far as implementing it once, but dropped it since didn't make a big difference in efficiency, and might become a pain to maintain. The idea is just to represent Some^n(v) (the Some constructor applied n times to v) as v when v is not an option, and Some^n(None) as n. To be more precise, since you want to distinguish it from (n : int), you represent it as a pointer in an unused memory area. Word addresses starting at 0 would be a possible approach. Semantically this was correct since ML polymorphism is not strong enough to allow the dynamic creation of Some^n(None) for an arbitrary n. That is, the maximum n is a function of the program, and not of its input. Remark however that since you have polymorphic recursion in O'Labl now, this is no longer true, meaning that you would need a runtime check to make sure that you don't create wrong values. By the way, and this also an answer to another mail I saw recently, O'Caml and O'Labl are going to merge soon. That is, O'Labl features will be merged into the official O'Caml release (beware though that the syntax may be slightly changed to fit everybody's taste). If you really think that having such costless options would be useful, it is the time to make pressure to have them included in the merger. Regards, Jacques > >>>>> "WC" == William Chesters writes: > > WC> The problem is that if you have a value of the type `int > WC> option option', you have to be able to distinguish between > WC> `None' and `Some None'! If both the enumeration-indirections > WC> are elided, you can't; if only one of them is, you have > WC> inconsistency which would presumably have to be resolved using > WC> whole-program optimisation or something. > ------------------------------------------------------ Jacques Garrigue, visiting INRIA from Kyoto University Jacques.Garrigue at inria.fr