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.2 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 BD9DCBC6A for ; Fri, 13 Oct 2006 14:14:29 +0200 (CEST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k9DCETbZ017181 for ; Fri, 13 Oct 2006 14:14:29 +0200 Received: from [84.58.144.248] (helo=gate.lan.gerd-stolpmann.de) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1GYLvm1Suo-0003S9; Fri, 13 Oct 2006 14:14:26 +0200 Received: from flakew.lan.gerd-stolpmann.de (fw.lan.gerd-stolpmann.de [192.168.1.1]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id 01106C0AD; Fri, 13 Oct 2006 14:14:25 +0200 (CEST) Subject: Re: [Caml-list] Why + vs +. but "fake" parametric polymorphism for < From: Gerd Stolpmann To: Diego Olivier FERNANDEZ PONS Cc: Jonathan Roewen , caml-list@inria.fr In-Reply-To: <20061013135650.48rwzsri8ws8coww@webmail.etu.upmc.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> Content-Type: text/plain Date: Fri, 13 Oct 2006 14:14:22 +0200 Message-Id: <1160741662.16545.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:a6865a839c0178d9aa0ce41878507ea2 X-Miltered: at concorde with ID 452F8325.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; parametric:01 polymorphism:01 gerd:01 stolpmann:01 pons:01 inference:01 optimise:01 mli:01 mli:01 inlined:01 gerd:01 stolpmann:01 viktoriastr:01 64293:01 darmstadt:01 Am Freitag, den 13.10.2006, 13:56 +0200 schrieb Diego Olivier FERNANDEZ PONS: > Bonjour, > > Quoting Jonathan Roewen : > > That's correct. As showed, specifying types somewhere (as I did with > > the return type, and someone else did for a given parameter), type > > inference deduces the types of the parameters and return values, > > allowing it optimise. > > As far as I remember it doesn't work when you specify the type in the > .mli file. And I never understood really why. 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. That an inlined function cannot be specialized afterwards has a similar reason, because the part of code generation is already over that decides whether the mono or polymorphic version is generated. This could be probably be changed (but I don't know the details, so maybe this would break something else). Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------