From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p0QMba7Z022367 for ; Wed, 26 Jan 2011 23:37:37 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYBANowQE1RZ90xkWdsb2JhbACkehUBAQIJCwoHEQMhvGyFTwSMKQ X-IronPort-AV: E=Sophos;i="4.60,382,1291590000"; d="scan'208";a="86360121" Received: from mtaout03-winn.ispmail.ntl.com ([81.103.221.49]) by mail4-smtp-sop.national.inria.fr with ESMTP; 26 Jan 2011 23:37:31 +0100 Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110126223731.WJAF23441.mtaout03-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Wed, 26 Jan 2011 22:37:31 +0000 Received: from romulus.metastack.com ([81.102.132.77]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20110126223731.NTEB20122.aamtaout01-winn.ispmail.ntl.com@romulus.metastack.com>; Wed, 26 Jan 2011 22:37:31 +0000 Received: from remus.metastack.local ([172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id p0QMbRq0003734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jan 2011 22:37:27 GMT Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%11]) with mapi; Wed, 26 Jan 2011 22:33:18 +0000 From: David Allsopp To: "'Jim Pryor'" , "'caml-list@inria.fr'" Thread-Topic: [Caml-list] Magic with fun (type t) ... ? Thread-Index: AQHLvaYJ/3QzNRjbm0eZvlFO076go5Pj1Wwg Date: Wed, 26 Jan 2011 22:33:17 +0000 Message-ID: References: <20110126221756.GA5907@vaio.jimpryor.net> In-Reply-To: <20110126221756.GA5907@vaio.jimpryor.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 81.102.132.77 X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=ZhKrKKPBFM8A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=jYKGEYzC4_k5_s6gkWkA:9 a=HYXhkyW8_C6ycmdhruD3vboBPxMA:4 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p0QMba7Z022367 Subject: RE: [Caml-list] Magic with fun (type t) ... ? Jim Pryor wrote: > I expect this is bad coding style, and should not be relied on. However, > I was surprised at the behavior, and wondered whether it was intended: > > # let f = fun (type t) x -> > let module M = struct exception E of t end in > M.E x;; > val f : 'a -> exn = > > f is polymorphic, as we expect: > > # f 1;; > - : exn = E 1 > # f "s";; > - : exn = E "s" > > But now notice: > > # f ();; > - : exn = E 0 > # f None;; > - : exn = E 0 > > It appears that non-heap values are always getting magicked into ints. I think there are other situations (I can't remember how you can force them) where the toploop displays the "wrong" things. As I understand it, the compiler/interpreter really has to jump through hoops sometimes to display the correct version of a value because the value representation throws away so much (virtually) of the typing information. > Has this been noted before? However, this is weird since () and the constructor None are not equal in OCaml-land (they happen to have equivalent representation, but that's not the same thing): # f () = f None;; - : bool = true David