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,
J

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
>