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=3.4 required=5.0 tests=AWL,DNS_FROM_RFC_POST, DNS_FROM_SECURITYSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 818F8BB84 for ; Sat, 1 Nov 2008 20:31:28 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiABAI9LDElKfSwci2dsb2JhbACTVj4BAQEKCwoHDwWoY4EAijUBAwEDg08 X-IronPort-AV: E=Sophos;i="4.33,527,1220220000"; d="scan'208";a="18754692" Received: from yx-out-2324.google.com ([74.125.44.28]) by mail3-smtp-sop.national.inria.fr with ESMTP; 01 Nov 2008 20:31:27 +0100 Received: by yx-out-2324.google.com with SMTP id 3so773811yxj.3 for ; Sat, 01 Nov 2008 12:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=4DPS6EfcJXToV9OME4yHQ/8EkxYxpTH1DlJ5dGyGXO8=; b=IIbd0GJmjHEWszypyqtjH5iubg/1OOZv8z4h3j0rwvofxIfr8LkDskZHv+arKjuV1z Xz4zlovnkA55CQkZsWXi2JymvizHMCLupftQL7DznbbvZCF34+TnWJZk81HuaexC6HfW DfEp11zBDIvMW+lJK/QWpB5xdmNmuVV3mqE54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=wTE0ptv5PMyu8CxRQyKgVluiAFCl0kJUkO7qf+Ml0wfLLaGbRlAe8w39aEaYy0CtID raquOUNaUbqOoUy0/RnPW7EO8vyYT9KXNsIHVaW+gbdoarQc/Fs5l+IUIzUvmAai2YT8 aTu1oJ4fw4q3b0HQb6u+DJte5eSg1UuU+zVow= Received: by 10.64.242.13 with SMTP id p13mr15418186qbh.43.1225567885989; Sat, 01 Nov 2008 12:31:25 -0700 (PDT) Received: from ?192.168.0.11? (ppp-70-242-67-240.dsl.stlsmo.swbell.net [70.242.67.240]) by mx.google.com with ESMTPS id 9sm11346817qbw.6.2008.11.01.12.31.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 01 Nov 2008 12:31:25 -0700 (PDT) Message-ID: <490CAE8A.8020408@gmail.com> Date: Sat, 01 Nov 2008 14:31:22 -0500 From: Edgar Friendly User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: David Allsopp Cc: 'Jacques Garrigue' , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Private types 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> In-Reply-To: <6788D960DAEA460EABA915DEA52D5CA2@countertenor> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 foo:01 integers:01 integers:01 inference:01 coercions:01 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. >> Would it be particularly difficult to, in the cases where type [x] is >> found but type [y] is expected, to try a (foo : x :> y) cast? > > +1! With reference my previous comment that "the type checker needs to know > if you meant that", there's still the option of using fully abstract types > if you wanted to avoid this kind of automatic coercion and have, say, > positive integers totally distinct from all integers without an explicit > cast. > Actually, I do see the use of two kinds of derived types: type positive = private int ( auto-coerced to int ) type category_id = new int (not auto-coerced to int - math not allowed) I assume there's some efficiency benefit to exposing the underlying type of category_id, if not then abstract types will quite suffice. > All said, I do see Jacques point of wanting to keep coercion and type > inference totally separate... though perhaps if coercions were only tried > during unification if at least one of the types in question is private that > would maintain a certain level of predictability about when they're used > automatically? > > > David > I'm happy moving down this slope of the compiler doing more of the work. Hopefully it's slippery, so it'll end up doing lots of work for me. E.