--- Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> wrote:
> There 's something fishy in struct type btype = B.btype end:
> if you're still inside B, you cannot refer to yourself as B.

Whoops, sorry.  You're right - the actual code uses more nested modules or type
renaming, which I left out of the sample code.

> Functors should incur three costs:
> * type abstraction cost: if you depend on abstract types, some data
>   structure accesses cannot be optimized.

I would like to see an example of an unoptimizable case

> * function abstraction cost: all imported functions and (some?)
>   exported functions cannot be called directly. Expensive.

So in the following code:

module MakeA (A : sig type x end) = struct
  let foo = ...
  module MakeB (B : sig val quux : ... end) = struct
    let bar = ...
  end
end

Both [foo] and [bar] will not cost anything to evoke, but [quux] will cost an
extra indirection since it was imported in the functor parameter?

> * structure access cost: you have to dereference to get to your
>   closures. I believe it's cheap compared to the function abstraction
>   cost. Xavier Leroy had recently some figures showing that a method
>   call (double indirection) was not that much more expensive than an
>   abstract function call.

Is this referring to closures over over local modules (using [let module])
only, or does it have an impact on top-level modules as well?

Can someone come up with a link to the figures mentioned above?

Thanks.

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners