From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA02689 for caml-redistribution; Tue, 23 Jun 1998 18:35:47 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA12882 for ; Tue, 23 Jun 1998 12:03:47 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id MAA17991; Tue, 23 Jun 1998 12:03:41 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA30881; Tue, 23 Jun 1998 12:03:40 +0200 (MET DST) Message-ID: <19980623120340.24172@pauillac.inria.fr> Date: Tue, 23 Jun 1998 12:03:40 +0200 From: Xavier Leroy To: William Chesters , caml-list@inria.fr Subject: Re: Functors ... References: <23811.199806151807@venus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <23811.199806151807@venus>; from William Chesters on Mon, Jun 15, 1998 at 07:07:38PM +0100 Sender: weis > But it seems that ocaml implements functors with dispatch tables, so > it runs a bit slowly. Is there some reason why functors cannot be > treated as normal code, much as C++ treats templates, and functions > from functors treated as candidates for inlining? To be exact, functions defined by functors are candidates for direct call and inlining; but it is true that functions taken from the functor parameter are always called via their closures (what you call "dispatch tables"). E.g. consider the following example: module F(X : sig val f : int -> int end) = struct let g x = 1 + X.f (x - 1) end module A = F(struct let f x = x * 2 end) ... A.g 10 ... The function g can be inlined at point of call in (A.g 10), but the call to function f (i.e. fun x -> x * 2) will not. The only reasons for this behavior is that OCaml's flow analysis and inline expander are fairly naive and concentrate on the most obvious opportunities for direct calls and inline expansion. In principle, the module language is terminating, so the compiler could simply generate a copy of the functor body at each functor application point, and work from here. This would allow more direct calls and inline expansion -- as much as if you'd written your code without functors -- but results in loss of separate compilation (the functor body is recompiled over and over again) and code bloat. C++ templates have precisely those two problems. So, I don't think we want to go all the way down to the C++ solution. But it is true that more opportunities for inlining (as in the example above) could certainly be exploited. - Xavier Leroy