[ocaml-platform] Unique file names

[Jeff Meister]

I apologize in advance if this message reflects a basic misunderstanding of
Alain's proposal.

I've been following this thread for the most part, and I keep seeing
references to a detail of Alain's proposal: that source file names must be
unique across projects. The OCaml compiler and other build tools
(ocamldep?) require this, and Alain proposes that programmers simply follow
a "long filename" convention. But this seems to defeat the purpose of
adding namespaces.

Indeed, the main (and perhaps only) problem I encounter where namespaces
would be useful is filename conflicts. For example, I might want to use
both packages foo and bar in my project, from different authors. Currently
I'd use ocamlfind to build against the packages, but since the compiler
doesn't know anything about packages, the source files they contain must
still have unique names. So, if foo has some utility functions in its
util.ml, and bar also has its own util.ml, my project won't compile.

Using Alain's proposal, how would I solve this conflict, where developers
have chosen not to follow the long filename convention? If I actually need
functions from both Util modules, am I expected to rename one of them to
Packagename_util.ml and refactor all module references in the third-party
codebase? This seems like exactly the situation we have now.

I think I have a similar view of namespaces as Didier (although I'm
certainly not as informed on the theory). A module in OCaml acts like a
namespace for the types/values/modules it contains, so developers of a
module don't hesitate to name their type "t", or their function "parse".
Contrast with C, where the language has no module support, so developers
must use long names like "yojson_parse" or "xmlm_parse" to avoid name
conflicts. It seems to me that requiring long filenames simply lifts this
restriction to the filename (top-level module) level. Surely we can do
better than C!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20130303/46a2402e/attachment.html>