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.9 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 2099CBB84 for ; Sat, 1 Nov 2008 02:52:28 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUBACJTC0lKfSwekGdsb2JhbACTVD4BAQEBCQkMBxEDrDZ/ikcBAwEDg06DLQ X-IronPort-AV: E=Sophos;i="4.33,525,1220220000"; d="scan'208";a="18736399" Received: from yx-out-2324.google.com ([74.125.44.30]) by mail3-smtp-sop.national.inria.fr with ESMTP; 01 Nov 2008 02:52:27 +0100 Received: by yx-out-2324.google.com with SMTP id 3so692892yxj.3 for ; Fri, 31 Oct 2008 18:52: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=9sl9DW0nX4oxgrIJ6aboQhnkimlPc/1EjWiwYQXDmHg=; b=bdT2cocbg5G+Nb4Vu5K6OTHkJ9w/owbvlOjuLVDAdiAlJ42ZBuUKmjxyhkEbLVUux7 NQjrRG6ltYSynRkCbkTm8sowpLGBwsFFcpEsXlB65P4IlBqspmvpitTMae/HT9Xjfv1t QWj1+p29qXTxvcxduqi9KKdwwdtkYHq9zU/ho= 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=MQXr7T9l/Rl3JrHC+g6BwkQyxEiGA/BKblqCzp2ptaUQAPZ9jU79cmfgM33dwim2uV oItxDA3ewyu02BOTr4ywsIQCZOQp61CfpFX/sW+G3VFM4mZd5BmQVl2qjxfqOMYipOf5 aEBltLnfpsVLRZAOH3YVXBpgBf4Q6sqa4Fglc= Received: by 10.65.241.15 with SMTP id t15mr14135052qbr.75.1225504346345; Fri, 31 Oct 2008 18:52:26 -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 25sm9265608qbw.1.2008.10.31.18.52.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 31 Oct 2008 18:52:25 -0700 (PDT) Message-ID: <490BB657.5050301@gmail.com> Date: Fri, 31 Oct 2008 20:52:23 -0500 From: Edgar Friendly User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Jacques Garrigue Cc: dra-news@metastack.com, 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> In-Reply-To: <20081031.090842.254669920.garrigue@math.nagoya-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; subtyping:01 unification:01 compiler:01 subtyping:01 compiler:01 casts:01 subtype:01 casts:01 inference:01 coercions:01 foo:01 subtype:01 ocaml:01 cheers:01 edgar:98 Jacques Garrigue wrote: > Your intuition is correct that it would theoretically be possible to > try subtyping in place of unification in some cases. The trouble is > that thoses cases are not easy to specify (so that it would be hard > for the programmer to known when he can remove a coercion), Does the compiler really get any information from an explicit cast that it can't figure out already? I can't come up with any example. > and that > subtyping is potentially very costly (structural subtyping is much > harder to check than the nominal subtyping you have in Java.) As the compiler needs to check that explicit casts are valid, I don't see any performance difference between explicit and implicit subtype casts. > So the current approach is to completely separate subtyping and type > inference, and require coercions everywhere subtyping is needed. > 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? > You can also compare that to the situation between int and float. > For most uses, int can be viewed as a subtype of float. However ocaml > separates the two, and requires coercion functions whenever you want > to use an int as a float. > Code isn't produced by a :> cast. As the internal representation of int and float differs, a coercion function isn't required. The internal representation of [private int] and [int] is the same, not to mention one is exactly the [private] of the other. > Cheers, > > Jacques Garrigue Merci, E.