From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 55306BC57 for ; Thu, 16 Dec 2010 16:15:50 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIBAE67CU3B/BfUkWdsb2JhbAALpEEBAQEBCQsKBxEDIcFthUoEin2DFw X-IronPort-AV: E=Sophos;i="4.59,355,1288566000"; d="scan'208";a="82905713" Received: from msa03.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.212]) by mail4-smtp-sop.national.inria.fr with ESMTP; 16 Dec 2010 16:15:50 +0100 Received: from [192.168.1.63] ([83.199.53.187]) by mwinf5d10 with ME id jrFo1f00M42M2AT03rFpFr; Thu, 16 Dec 2010 16:15:49 +0100 Message-ID: <4D0A2D24.8090401@frisch.fr> Date: Thu, 16 Dec 2010 16:15:48 +0100 From: Alain Frisch User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Louis Gesbert Cc: caml-list@inria.fr Subject: Re: [Caml-list] Implicitely abstracted type References: <4D0A14BE.9080305@mlstate.com> In-Reply-To: <4D0A14BE.9080305@mlstate.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; frisch:01 frisch:01 abstracted:01 functor:01 functor:01 supertype:01 compiler:01 functor's:01 ctype:01 nondep:01 decl:01 nondep:01 admittedly:01 wrote:01 abstract:01 On 12/16/2010 02:31 PM, Louis Gesbert wrote: > What happens is that a sum-type defined in a module can implicitely be > turned into abstract because of its inner contents. Here is an explanation of this behavior. When applying a functor of type functor(X:S1) -> S2 to a module of type T, the module type for the result can be obtained in two different ways: (1) T is a path: the module type is obtained by substituting X with T in S2. (2) T is not a path: the module type is obtained by computing the smallest supertype of S2 that doesn't contain X anymore (under the extra assumption that X has type T). In your example, you are in case (2), and the only way (of which the compiler is aware) to get rid of the dependency on the functor's formal argument is to turn a concrete type declaration into an abstract one. If you are interested in the implementation, this happens in the function Ctype.nondep_type_decl (where a Not_found exception raised by nondep_type_rec is turned into a Type_abstract). Admittedly, this fallback behavior of turning automatically a concrete type declaration into an abstract one is not completely natural. As far as I can tell, it would be straightforward to add a warning in this situation. Do you want to fill a feature request? Alain