Oh, I missed that detail. That actually could work quite nicely. Though it's a bit of a messy build script, it's something we could write generically to work well on any "project". The only remaining remnant of the "prefixed" namespace is in myLib.mli/.ml

module MyModule = MyLibMyModule
module Utils = MyLibUtils

It would be nice to eliminate that as well, but I could imagine auto-generating these module alias mappings. This sounds like a nice workaround the namespace issue, but do you think it would be worth supporting module aliases themselves as a form of namespacing at compilation time, so that this intermediate prefixed compilation artifact isn't needed?

Thank you for the help,

On Sun, Dec 28, 2014 at 1:26 PM, Leo White <lpw25@cam.ac.uk> wrote:

Jordo <jordojw@gmail.com> writes:

> Thank you for the reply, Leo. One of the requirements was that developers be able to name their internal modules as they
> see fit without having to fear naming collisions. It's also required that file names correspond directly to module names
> (or at least we retain the capability to do so). It appears in this solution you suggested, developers still must prefix
> their file names in order to avoid collisions.

None of the source files have prefixed names, only intermediate files
(that is why you use `-o`). For both reading the source code and using
the library through `MyLib.Foo`, the prefix does not appear.

Regards,

Leo