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=0.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 0C98CBBC1 for ; Wed, 20 Feb 2008 06:01:44 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFNDu0fAXQInh2dsb2JhbACQUgEBAQgKKYEUnXU X-IronPort-AV: E=Sophos;i="4.25,379,1199660400"; d="scan'208";a="8302366" Received: from concorde.inria.fr ([192.93.2.39]) by mail1-smtp-roc.national.inria.fr with ESMTP; 20 Feb 2008 06:01:44 +0100 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m1K51hdi017619 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 20 Feb 2008 06:01:43 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJBDu0eFBoIFh2dsb2JhbACQUgEBAQgKKYEUnXM X-IronPort-AV: E=Sophos;i="4.25,379,1199660400"; d="scan'208";a="7488044" Received: from rabbit.math.nagoya-u.ac.jp ([133.6.130.5]) by mail2-smtp-roc.national.inria.fr with ESMTP; 20 Feb 2008 06:01:35 +0100 Received: from localhost (millas [172.16.30.29]) by rabbit.math.nagoya-u.ac.jp (8.12.11/3.7W) with ESMTP id m1K51Rmn005132; Wed, 20 Feb 2008 14:01:27 +0900 (JST) Date: Wed, 20 Feb 2008 14:01:27 +0900 (JST) Message-Id: <20080220.140127.238245617.garrigue@math.nagoya-u.ac.jp> To: vanicat@debian.org Cc: caml-list@inria.fr Subject: Re: [Caml-list] Re: polymorphic variants and promotion From: Jacques Garrigue In-Reply-To: <871w796rj7.dlv@maison.homelinux.org> References: <926565e50802190223r456d0ec2we4b8a4f51b134f42@mail.gmail.com> <871w796rj7.dlv@maison.homelinux.org> X-Mailer: Mew version 4.0.69 on Emacs 22.0.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 47BBB437.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; variants:01 compiler:01 compiler:01 unification:01 abbreviation:01 polymorphic:01 typing:01 caml-list:01 remi:01 vanicat:01 vanicat:01 explicitly:02 explicitly:02 inferred:02 inferred:02 From: Remi Vanicat > Well, you have to explicitly coerce : > > let h a = function > | [] -> g a > | xs -> (List.fold_left f a xs : [ `A of _ ] :> [> `A of _ | `B of _ ]) ;; > > What I don't understand is why this : > > let h a = function > | [] -> g a > | xs -> (List.fold_left f a xs :> [> `A of _ | `B of _ ]) ;; > > do not work ? I understood that we need to explicitly coerce, but the > [ `A of _ ] is just the information the compiler will find by itself, > why must we give it to it again ? Because we cannot always be sure that the compiler will infer it at the right time. I.e., we would end up with some programs having different typing behaviours when the above application is inferred as [`A of _] and when a less precise type is inferred, which could cause unification errors somewhere else... We are currently considering allowing the above kind of abbreviation when both the source and target are ground types (i.e. do not contain type variables). But this would not include the above example. Jacques Garrigue