From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2MEeKHh010666 for ; Thu, 22 Mar 2012 15:40:26 +0100 X-IronPort-AV: E=Sophos;i="4.73,630,1325458800"; d="scan'208";a="150733664" Received: from arbois.inria.fr (HELO [128.93.11.104]) ([128.93.11.104]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 22 Mar 2012 15:40:26 +0100 Message-ID: <4F6B39DA.7080701@inria.fr> Date: Thu, 22 Mar 2012 15:40:26 +0100 From: Didier Remy Reply-To: Didier.Remy@inria.fr Organization: INRIA Rocquencourt User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: caml-list@inria.fr References: <20120322095143.GA30016@voyager> <4F6B2B83.3070003@gmail.com> In-Reply-To: <4F6B2B83.3070003@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Funny name for a type variable in the output: should this be filed on the BTS? > Jacques Garrigue recently implemented a patch that tries to keep user-provided > type names when printing out types, and also when giving error > messages. In your > example, there probably is an internal variable that's called "a" because of the > type name you provided. Some wizardry happens with GADTs, so another type > variable is generated. The other one ends up being printed, and because it's > called "a" too, the type-checker has to find another suitable name. > > Or something like that. Maybe change type a b. to type foo bar. will give > different results :). This is an explanation of why it is printed so. The question of Roberto is rather whether this is intended or should be fixed (call it a bug or anything else). If the intention is that types should be printed with _best_ variable names for some meaning of best (shortest, reuse source variable names whenever meaningful, etc.), I do not see any reasonable definition of "best" that would imply printing 'a1 in Roberto's example instead of 'a, while 'a is printed in the two following examples (especially the second one) while it appears in the source---and also unified with int in the second example. let id : 'a -> 'b = function x -> 1 id : 'a -> 'a let foo : 'b -> 'a = function x -> fst x; 1;; val foo : 'a * 'b -> int = Thus, I would tend to call this a bug (a something that should be fixed if possible)... Didier