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 HAA17375; Fri, 27 Aug 2004 07:43:41 +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 HAA16088 for ; Fri, 27 Aug 2004 07:43:40 +0200 (MET DST) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i7R5hbhs000466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Aug 2004 07:43:39 +0200 Received: (qmail 3620 invoked from network); 27 Aug 2004 05:43:37 -0000 Received: from shell2.speakeasy.net ([69.17.110.71]) (envelope-sender ) by mail1.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 27 Aug 2004 05:43:37 -0000 Date: Thu, 26 Aug 2004 22:43:37 -0700 (PDT) From: brogoff To: Jacques GARRIGUE cc: caml-list@inria.fr Subject: Re: [Caml-list] Re: OCaml typechecking bug? (PR#3104) [about phantom types] In-Reply-To: <20040827.102827.50023947.garrigue@kurims.kyoto-u.ac.jp> Message-ID: References: <200408261703.TAA23962@pauillac.inria.fr> <20040827.102827.50023947.garrigue@kurims.kyoto-u.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at nez-perce with ID 412ECA09.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; brogoff:01 brogoff:01 caml-list:01 bug:01 jacques:01 datatypes:01 datatype:01 ocaml:01 ocaml:01 typechecking:01 equality:01 speakeasy:01 surprising:01 phantom:01 phantom:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, 27 Aug 2004, Jacques GARRIGUE wrote: [...snip...] > Not surprising: the distinction is not between built-in and > user-defined, but between abbreviation types and datatypes (which > share the same syntax in ocaml, but have different syntax in most > other dialects) [...snip...] > This behaviour is perfectly normal. > In the above signature, the type t is not phantom at all. > It will be expanded to int before checking equality, so the type > argument will be completely ignored altogether. OK, ignore my request for further explanation, it all makes good sense now, even though it was counterintuitive behavior at first. It does suggest that making a syntactic distinction between type abbreviation and datatype definition a la SML is a good idea. I never ran across this behavior before since I assumed the phantom type had to be abstract and always coded it that way. All of this phantom type stuff makes me wish we had dependent types anyways... -- 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