[ocaml-platform] Unique file names

Romain Bardou romain.bardou at inria.fr
Mon Mar 4 15:18:16 GMT 2013


Hello,

This seems reasonable.

But I would still prefer to name my file "quadtree". I'm sure the 
possibility of a "-unit-name-prefix video3d" compilation flag has been 
discussed already. I'll go read and see what are the counter-arguments...

Cheers,

-- 
Romain

Le 04/03/2013 15:49, Edgar Friendly a écrit :
> Romain,
>
> The way I see your example working out is something like:
>
> video3D.ns:  module Quadtree = Video3D_Quadtree
> batteries.ns: require video3D <other declarations>
> core.ns: require video3D <other declarations>
>
> Then the client code would be something like:
>
> foo.ml <http://foo.ml>:
> require Core
> let _ = Quadtree.do_operation x y z
>
> 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.
>
> E.
>
>
> On Mon, Mar 4, 2013 at 9:28 AM, Romain Bardou <romain.bardou at inria.fr
> <mailto:romain.bardou at inria.fr>> wrote:
>
>     Hello,
>
>     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.
>
>     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".
>
>     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.
>
>     Long names feel like having to write code like this:
>
>     type 'list_t_a list_t =
>        | List_empty
>        | List_cons of 'list_t_a * 'list_t_a list_t
>
>     let rec list_map list_map_f list_map_l =
>        match list_map_l with
>          | List_empty ->
>              List_empty
>          | List_cons (list_map_value, list_map_tail) ->
>              let list_map_value = list_map_f list_map_value in
>              let list_map_tail = list_map list_map_f list_map_tail in
>              List_cons (list_map_value, list_map_tail)
>
>     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.
>
>     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.
>
>     Cheers,
>
>     --
>     Romain Bardou
>
>     _________________________________________________
>     Platform mailing list
>     Platform at lists.ocaml.org <mailto:Platform at lists.ocaml.org>
>     http://lists.ocaml.org/__listinfo/platform
>     <http://lists.ocaml.org/listinfo/platform>
>
>



More information about the Platform mailing list