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 TAA08718 for caml-redistribution; Mon, 11 Oct 1999 19:26:05 +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 BAA04274 for <weis@pauillac.inria.fr>; Mon, 11 Oct 1999 01:28:19 +0200 (MET DST)
From: chet@watson.ibm.com
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18])
	by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id BAA27009;
	Mon, 11 Oct 1999 01:28:17 +0200 (MET DST)
Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97])
	by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id TAA11902;
	Sun, 10 Oct 1999 19:28:16 -0400
Received: from nautilus.chet.org (lig32-224-156-103.us.lig-dial.ibm.com [32.224.156.103]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with ESMTP id TAA19824; Sun, 10 Oct 1999 19:28:10 -0400
Received: from bismarck.chet.org (root@bismarck.chet.org [192.168.10.15])
	by nautilus.chet.org (8.8.8/8.8.8/Debian/GNU) with ESMTP id SAA09997;
	Sun, 10 Oct 1999 18:39:09 -0400
Received: from bismarck.chet.org (chet@localhost [127.0.0.1])
	by bismarck.chet.org (8.8.8/8.8.8/Debian/GNU) with ESMTP id SAA17970;
	Sun, 10 Oct 1999 18:36:31 -0400
Message-Id: <199910102236.SAA17970@bismarck.chet.org>
To: William Chesters <williamc@dai.ed.ac.uk>
cc: caml-list@inria.fr, Pierre.Weis@inria.fr
Subject: Re: Proposal for study: Add a categorical Initial type to ocaml 
In-reply-to: Your message of Sun, 10 Oct 1999 22:05:26 BST.
             <24984.199910102105@buckie> 
Date: Sun, 10 Oct 1999 18:36:30 -0400
Sender: weis


I read the referenced note

[http://caml.inria.fr/caml-list/0967.html]

and while I agree with most of what's said there, I think that putting
the "option" attribute onto a field would reduce its value.

Specifically, it is a highly common (albeit problematic) idiom in C,
C++, Java, and other languages, to program with a pointer to X, which
is perhaps null, and is only checked late, at the point when it is
destructured somehow.

That sort of idiom would not be possible to capture -- when we fetch
the value of an "option" field, we are implicitly asking for the field
to be checked for non-null-ness.

In other words, I think that "nullability" is a useful property of
types in general, and not merely of types of fields.

--chet--