<div dir="ltr"><div><div><div>I apologize in advance if this message reflects a basic misunderstanding of Alain's proposal.<br><br></div>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.<br>
<br></div>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 <a href="http://util.ml">util.ml</a>, and bar also has its own <a href="http://util.ml">util.ml</a>, my project won't compile.<br>
<br></div><div>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.<br>
</div><div><br></div>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!<br>
</div>