<div dir="ltr">Romain,<div><br><div style>The way I see your example working out is something like:</div><div style><br></div><div style><font face="courier new, monospace">video3D.ns:  module Quadtree = Video3D_Quadtree</font></div>
<div style><font face="courier new, monospace">batteries.ns: require video3D <other declarations></font></div><div style><font face="courier new, monospace">core.ns: require video3D <other declarations></font></div>
<div style><br></div><div style>Then the client code would be something like:</div><div style><br></div><div style><font face="courier new, monospace"><a href="http://foo.ml">foo.ml</a>: </font></div><div style><font face="courier new, monospace">require Core</font></div>
<div style><font face="courier new, monospace">let _ = Quadtree.do_operation x y z</font></div><div style><br></div><div style>The client just sees a Quadtree module for them to use, because the compiler reads the core.ns file, finds its 'require', reads the video3D.ns file, and puts a module Quadtree into the environment that's connected to the Video3D_quadtree compunit.</div>
<div style><br></div><div style>E.</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 4, 2013 at 9:28 AM, Romain Bardou <span dir="ltr"><<a href="mailto:romain.bardou@inria.fr" target="_blank">romain.bardou@inria.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
It seems to me that long names break modularity. By modularity I mean the ability to name a unit (a file, a value...) with no knowledge of its environment.<br>
<br>
Let's say I am developing project "Video3D" for which I developed a "Quadtree" module. I name it "Video3D_Quadtree". Now, let's say that Batteries and Core want to integrate my quadtree implementation. They will rename the module as "Batteries_Quadtree" and "Core_Quadtree".<br>

<br>
There is no way to chose a name that does not depend on the environment if I use long unique names. Long unique names are explicitely giving up on modularity.<br>
<br>
Long names feel like having to write code like this:<br>
<br>
type 'list_t_a list_t =<br>
  | List_empty<br>
  | List_cons of 'list_t_a * 'list_t_a list_t<br>
<br>
let rec list_map list_map_f list_map_l =<br>
  match list_map_l with<br>
    | List_empty -><br>
        List_empty<br>
    | List_cons (list_map_value, list_map_tail) -><br>
        let list_map_value = list_map_f list_map_value in<br>
        let list_map_tail = list_map list_map_f list_map_tail in<br>
        List_cons (list_map_value, list_map_tail)<br>
<br>
Everything which is defined in unit U is prefixed by "U_". Here, I have the "list" unit (the module) and the "list_map" unit. But thanks to modularity I can choose any name for "list_map_f" and "list_map_l". Because I am inside unit "list_map", these names are redundant and I can use "f" and "l" instead.<br>

<br>
It should be the same for compilation units: I should be able to name my module "Quadtree". Namespaces should then provide a way to integrate this name in another environment, if needed.<br>
<br>
Cheers,<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Romain Bardou</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
Platform mailing list<br>
<a href="mailto:Platform@lists.ocaml.org" target="_blank">Platform@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/platform" target="_blank">http://lists.ocaml.org/<u></u>listinfo/platform</a><br>
</div></div></blockquote></div><br></div>