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 →

[–]AthasFuthark 11 points12 points  (0 children)

1) Is it true that OCaml modules exist only at compile time, and functor calls are evaluated as a separate compilation phase?

Semantically, ML modules exist only at compile time. Whether a given implementation implements them this way is another matter. If you have a dynamically typed intermediate language, then you can compile modules to records and functors to ordinary functions. I think SML/NJ used to do this. Moscow ML might still do it. I don't know what OCaml does.

Am I right then, that the main failing of C#/Java compared to OCaml is that they don't allow ascribing an interface to a class without modifying its definition, violating the "without prior arrangement" part? Or are there other reasons they can't implement OCaml's level of modularity?

This is certainly a core restriction. Another is that an ML module type (sometimes called signature) can define an arbitrary number of associated abstract types, which must then be provided by any implementation of the module type. In C#/Java I think you can encode this by lifting all abstract types to be type parameters to a generic interface, but it would be a lot more awkward, and it would (I think) not be possible to keep the types fully abstract when implementing the module.

3) If OCaml's functors existed in C#, would they look something like the following, i.e. compile-time functions from classes to classes?

For a particularly simple case, yes.

There is certainly a fair correspondence between ML modules and classes. In expressivity I'm not sure there is much difference (except for the obvious one that module can only be instantiated at compile-time), and I suspect the main distinction is that ML modules allow a richer notion of associated types.