Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: William Chesters <williamc@dai.ed.ac.uk>, caml-list@inria.fr
Subject: Re: Functors ...
Date: Tue, 23 Jun 1998 12:03:40 +0200	[thread overview]
Message-ID: <19980623120340.24172@pauillac.inria.fr> (raw)
In-Reply-To: <23811.199806151807@venus>; from William Chesters on Mon, Jun 15, 1998 at 07:07:38PM +0100

> 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





  reply	other threads:[~1998-06-23 16:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-06-15 18:07 Functors William Chesters
1998-06-23 10:03 ` Xavier Leroy [this message]
1998-06-23 17:00   ` Functors Thorsten Ohl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19980623120340.24172@pauillac.inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=williamc@dai.ed.ac.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox