From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=2.0 required=5.0 tests=AWL,DNS_FROM_SECURITYSAGE, RCVD_IN_SORBS_WEB autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 0DFA6BB84 for ; Sat, 1 Nov 2008 21:19:11 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQBAApXDElRZ90wkWdsb2JhbACKHIl4AQEBAQkLCgcRA7Qig1I X-IronPort-AV: E=Sophos;i="4.33,527,1220220000"; d="scan'208";a="31015646" Received: from mtaout02-winn.ispmail.ntl.com ([81.103.221.48]) by mail4-smtp-sop.national.inria.fr with ESMTP; 01 Nov 2008 21:19:10 +0100 Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20081101201910.PXJA13155.mtaout02-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Sat, 1 Nov 2008 20:19:10 +0000 Received: from romulus.metastack.com ([81.102.132.77]) by aamtaout02-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20081101201905.YMQH21638.aamtaout02-winn.ispmail.ntl.com@romulus.metastack.com>; Sat, 1 Nov 2008 20:19:05 +0000 Received: from countertenor ([149.254.192.208]) (authenticated bits=0) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id mA1KIuDS031402 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 1 Nov 2008 20:19:01 GMT From: "David Allsopp" To: "'Edgar Friendly'" Cc: "'Jacques Garrigue'" , References: <340C8DB35D244173AE527238DB359A19@countertenor> <04092D60-3BB6-49A6-8A04-0BFE3A2081BD@erratique.ch> <5687D906367C49F981398A97A5966E09@countertenor> <20081031.090842.254669920.garrigue@math.nagoya-u.ac.jp> <490BB657.5050301@gmail.com> <6788D960DAEA460EABA915DEA52D5CA2@countertenor> <490CAE8A.8020408@gmail.com> Subject: RE: [Caml-list] Private types Date: Sat, 1 Nov 2008 20:18:49 -0000 Organization: MetaStack Solutions Ltd. Message-ID: <8E52E728B9D54B9AAF6219C7518248A7@countertenor> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ack8WG7FEdjn0tzkTa6wMYIVQTYrJwABSOtw In-Reply-To: <490CAE8A.8020408@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Scanned-By: MIMEDefang 2.64 on 81.102.132.74 X-Cloudmark-Analysis: v=1.0 c=1 a=hw4b1vcqMvI6tizNyk4A:9 a=_iIPp7V_rNrqod0VINcLTx6AAFkA:4 a=tXPUrm4B3N8A:10 X-Spam: no; 0.00; checker:01 infers:01 unify:01 coerced:01 compiler:01 variants:01 checker:01 unify:01 variants:01 compiler:01 unification:01 edgar:98 polymorphic:01 polymorphic:01 wrote:01 Edgar Friendly wrote: > David Allsopp wrote: > > > Without the full coercion for x you'll get a type error because the type > > checker infers that the type of the [if] expression is [t] from the > > [then] branch and then fails to unify [> `B of int ] with [t] unless the > > type of [x] is first coerced to [> t ]. If the compiler were to try (x : > > t : [> t ]) in all those instances I think that would render polymorphic > > variants pretty unusable ... the type checker needs to know that you > > meant to do that or everything will unify! > > Okay, you claim we shouldn't automatically open polymorphic variants. I > don't see why auto->ing polymorphic types is really a problem. If the > later code (receiving the returned value) can't handle the [> ] type, > that type error will stop things (although it won't point out where the > [> ] came from). This seems one case where the compiler can easily DWIM > the correct result. I agree that the error will still show up somewhere if there is an error - but remember that a closed polymorphic variant type required an annotation in the first place (in this case, the type [t] and the explicit type annotation to use it)... so having made the explicit choice to declare the type closed (which you either do to declare module interfaces or to try to trap errors) the last thing (I'd say!) you want is the compiler trying to open them back up on every unification failure! David