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.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id A6A1FBC69; Fri, 13 Oct 2006 15:15:32 +0200 (CEST) Received: from ipmail02.adl2.internode.on.net (ipmail02.adl2.internode.on.net [203.16.214.141]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k9DDFTl0009285; Fri, 13 Oct 2006 15:15:31 +0200 Received: from ppp229-164.lns3.syd7.internode.on.net (HELO rosella) ([59.167.229.164]) by ipmail02.adl2.internode.on.net with ESMTP; 13 Oct 2006 22:45:20 +0930 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AY8CAO8tL0U X-IronPort-AV: i="4.09,306,1157293800"; d="scan'208"; a="28011942:sNHT47715815" Subject: Re: [Caml-list] Why + vs +. but "fake" parametric polymorphism for < From: skaller To: Luc Maranget Cc: Diego Olivier FERNANDEZ PONS , Gerd Stolpmann , caml-list@inria.fr In-Reply-To: <20061013130100.GA10977@yquem.inria.fr> References: <1160630285.7649.18.camel@monad> <20061012.144518.115907516.garrigue@math.nagoya-u.ac.jp> <1160632737.7649.34.camel@monad> <20061013135650.48rwzsri8ws8coww@webmail.etu.upmc.fr> <1160741662.16545.9.camel@localhost.localdomain> <20061013144605.vvzwfl4pw0kockw8@webmail.etu.upmc.fr> <20061013130100.GA10977@yquem.inria.fr> Content-Type: text/plain Date: Fri, 13 Oct 2006 23:15:17 +1000 Message-Id: <1160745317.16199.17.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 452F9171.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; parametric:01 polymorphism:01 maranget:01 gerd:01 stolpmann:01 mli:01 mli:01 abstracting:01 replacing:01 variance:01 val:01 variants:01 2006:98 sourceforge:01 luc:01 On Fri, 2006-10-13 at 15:01 +0200, Luc Maranget wrote: > > Bonjour, > > > > Quoting Gerd Stolpmann : > > >Well, this is quite easy. The .mli file does not influence code > > >generation. Code is generated when the .ml file is compiled, and it is > > >only _checked_ afterwards if the types match the .mli file. This is > > >simply the logic of the .mli. > > > > Very well, but why ? > > > > Diego Olivier > > By design, I guess. Well here's a waffly explanation: Interfaces act as constraints on what a module exports. These constraints permit eliding some symbols. They also permit abstracting types, or replacing types with sub/supertypes (depending on variance) or specialisations. The public,for example, could permitted to call a polymorphic function only monomorphically: let ident x = x is polymorphic but the mli file can say: val ident : int -> int This particular factor is almost essential working with polymorphic variants. I find this constraint mechanism is sometimes annoying BUT I'd miss it if it were missing! It's annoying because you tend to get unintuitive type error diagnostics, and because one is often forced to duplicate definitions from *.ml files in *.mli files for no apparent reason (there is, of course, a reason). -- John Skaller Felix, successor to C++: http://felix.sf.net