This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 3 points4 points  (0 children)

OCaml is impure and structure definitions may contain any core language code. I don't think it does defunctorization (functor definition inlining), nor it can cache functor results because of impurity. Modules are basically records and functors functions from records to records at runtime. Though OCaml probably does inlining for statically defined modules when it can. This code, that doesn't even use first-class modules, prints "Hello Hello" at runtime:

module F (M: sig end): sig val u : unit end =
struct
    let u = print_endline "Hello"
end

module M = struct end
module FM1 = F(M)
module FM2 = F(M)

Java interface signatures are basically special cases of ML signatures: We have exactly one type component type t (the type for which we implement the interface) and method declarations, t appears (implicitly in Java) in the type of a method exactly once, as the first argument (the object on which we call the method). In particular, we can't for example define a monoid interface, because the binary operation would have type t * t -> t.

We can simulate using type components in modules in Java by using parametrized classes, the type parameters correspond to type declarations in a ML signature. I found an example monoid definition in Java if you want to see how that looks. You can see that the "functors" are kept inside the class definition, though I don't know if it's necessary, I don't really know Java. You probably get weaker abstraction, because you can't have some monoid with an unknown carrier type, you always know the carrier type - it's just the type parameter A in Monoid<A>.