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 TAA32051 for caml-redistribution; Tue, 19 Oct 1999 19:25:49 +0200 (MET DST) 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 TAA19968 for ; Mon, 18 Oct 1999 19:54:50 +0200 (MET DST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id TAA10080 for ; Mon, 18 Oct 1999 19:54:48 +0200 (MET DST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 18 Oct 1999 10:13:22 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Oct 1999 10:13:21 -0700 Message-ID: <783D93998201D311B0CF00805FEAA07B7E8F7B@RED-MSG-42> From: Manuel Fahndrich To: "'skaller'" Cc: caml-list@inria.fr Subject: RE: Proposal for study: Add a categorical Initial type to ocaml Date: Mon, 18 Oct 1999 09:48:14 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: weis I was comparing using Obj.magic in the particular case of writing an extensible array module vs. adding uninitialized values to the language. In the second case, having uninitialized values as a language feature will make code more brittle since the uninitialized exception may be raised anywhere in the code where a field access is made. In the first case, the module can be constructed such that the use of Obj.Magic can be deemed safe, namely by requiring all accesses of extensible arrays to go through the module and that appropriate checks are in place there. -Manuel -----Original Message----- From: skaller [mailto:skaller@maxtal.com.au] Sent: Sunday, October 17, 1999 2:19 AM To: Manuel Fahndrich Cc: caml-list@inria.fr Subject: Re: Proposal for study: Add a categorical Initial type to ocaml Manuel Fahndrich wrote: > > I did not word what I meant correctly. i thought you did OK .. >In the case of initial values, errors > can occur anywhere in the code, namely, whenever I access an uninitialized > value. Since these values can live in records, and the records can be passed > around, the error can occur anywhere. > > Now, with a well-defined and encapsulated use of Obj.magic, such errors can > be avoided. E.g. in the extensible array case, I can write the module in > such a way that no matter what code I write outside of that module (not > using Obj.magic), it cannot result in an error. I'm sorry. I do do not follow. You argument is comparative, and appears unsound because it fails to make a distinction. The magical encapsulation of Obj.magic within a module or class, can be applied to initials just the same: maintaining the invariant 'uninitialised values are initialised before use' is the same in both cases, only the value representing it differs. Where 'initial' might be used, obj.magic could be used too. References to both may be propagated without error (and indeed that is the whole point): the only difference is that using an initial value is guarranteed to cause an exception to be raised, whereas using a magical value offers no guarrantees, and could core dump. The initial value is therefore easier to debug. The other difference seems to be that it is polymorphic whereas obj.magic needs explicit casting. -- John Skaller, mailto:skaller@maxtal.com.au 1/10 Toxteth Rd Glebe NSW 2037 Australia homepage: http://www.maxtal.com.au/~skaller downloads: http://www.triode.net.au/~skaller