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.1 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 discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 5C568BC69 for ; Fri, 13 Oct 2006 15:53:49 +0200 (CEST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id k9DDrmdV016720 for ; Fri, 13 Oct 2006 15:53:48 +0200 Received: from [84.58.144.248] (helo=gate.lan.gerd-stolpmann.de) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1GYNTp4BJi-0003Mk; Fri, 13 Oct 2006 15:53:42 +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 9B63DC0AD; Fri, 13 Oct 2006 15:53:38 +0200 (CEST) Subject: Re: [Caml-list] Why + vs +. but "fake" parametric polymorphism for < From: Gerd Stolpmann To: Diego Olivier FERNANDEZ PONS Cc: caml-list@inria.fr In-Reply-To: <20061013144605.vvzwfl4pw0kockw8@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> <1160741662.16545.9.camel@localhost.localdomain> <20061013144605.vvzwfl4pw0kockw8@webmail.etu.upmc.fr> Content-Type: text/plain Date: Fri, 13 Oct 2006 15:53:37 +0200 Message-Id: <1160747618.16545.24.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 discorde with ID 452F9A6C.001 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 gerd:01 stolpmann:01 mli:01 mli:01 ocaml:01 model:01 compilation:01 compilation:01 ocaml:01 inlining:01 Am Freitag, den 13.10.2006, 14:46 +0200 schrieb Diego Olivier FERNANDEZ PONS: > 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 ? I think the answer is that ocaml uses the model of separate compilation. That means you can compile the top-level modules separately (in a certain order) and link them later together. Of course, this implies that the compilation and code generation steps must be applied in a certain order. Ocaml is already cleverer than most other implementations of separate compilation because it allows to defer some parts of code generation (the so-called cross-module inlining feature). One can imagine different models. For example, you could do code generation when a function is _used_, not when the function is seen by the compiler for the first time. That way, you can always specialize the function in the generated code to what the types allow. Such a model is seen as quite problematic, however, because it is unclear how to create pre-compiled libraries. (In the C++ world often a variation of this model is used, and is an endless source of problems.) Of course, you may ask why Ocaml's inlining feature isn't clever enough to do late specialisation, at least of functions that can be inlined. I don't know. 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 ------------------------------------------------------------