Make codept as a library (1/n)

[dinosaure]

In my objective to be able to export a nice library to calculate dependencies from the codept project, several points need to be clarify to improve step by step the project - this is why there is a 1/n. Each of these points will be of interest in what I think is a good library and we can discuss the interest of each and see if it is worth spending time on it or not. So this is going to be a series of questions possibly associated with PRs.

The first point I'd like to highlight is the exposure of the guys. From what I can see from the project, the use of modules often implies implicit knowledge about the use of certain types which only becomes clear through their use. A first step that would help clarify the interest of the modules (and then export them as a library) would be to:

1. abstract some of the types,
2. add some functions to create values corresponding to the types and,
3. add some documentation to finally delimit the interest of these modules in relation to each other

The first modules in which there is surely a particular interest to abstract would be the Name, Path and Namespaced modules. For the last two modules - and I've noted this several times in the code - one could ensure that a Path cannot be empty (eg. an empty list). This would partially change the Namespaced type, which would have an optional namespace (currently embodied as an empty list).

What do you think about this change?

[Octachron]

It is good idea, it is true that the Namespaced module has evolved to conflate namespaced path and non-empty paths. It probably a good idea to split back the two concepts.

[dinosaure]

The issue is more difficult than I imagined. Currently. the type Name.t has more an equivalence with a string than a string which refer to a module name. It seems that the usage of it is:

• as a module name
• as a path

It seems that these views can cohabit but it's hard to fix then a more restrictive definition of Name.t along the code. My second round is to introduce a new module Mod.t which refers to a real module name (no path, etc.), extend Namespaced.t with that and try to find where I can prolifere this type along the code base (without breaking tests).

[Octachron]

Maybe more Modname than Mod?, but yes the current Name module is a home-grew extension for String.

[dinosaure]

Just to follow up a discussion with @Octachron, Modname was a nice idea but, due to the namespace integration, we have different view about a module: as a filepath and as a module name. We decided to integrate Modname.t as I explained above plus a new Unitname.t module which will provide these views.