Split alt

[dbuenzli]

It was a little bit difficult for me to see through the structure in https://github.com/hammerlab/oml/pull/174. So continued the branch by rewriting a bit the organization of the source tree and to use topkg to build the libraries (porting the test suite and other idiosyncrasies of your build system would take too me much time).

There are two libraries oml and oml_full respectively advertised as oml and oml.full in ocamlfind and which are accessible through the Oml and Oml_full namespacing modules. Rather than using -pack which has a lot of problems we prefix submodules by either oml_ or omlf_ according to the library. These libraries are located in src in src-full in the source tree (I kept the subdirs, but I would personally remove them up to ease source navigation).

Regarding documentation the usual way I solve this is to write the signatures and the documentation in the interface ofthe namespacing modules rather than in the modules mlis and use module type of (a few examples bos, uucp, topkg). This also allows you to ensure that your API doesn't export internal names ($Prefix_* ones). This has however the following disavantage 1) If you use mlis for your internal modules then you have to write the type twice, I sometimes do, I sometimes don't. 2) It will prevent you from using module aliases. odoc will certainly improve the documentation on this front as it should be able to fully support the constructs of the module system.

To makeOml and Oml_full really compatible at the type level some equations would be needeed in Oml_full's includes to equate types. In order to this the Oml_full module should be structured a bit differently than is now. In each submodule you should systematically include the corresponding base Oml signature with type equalities to Oml's defs and then add the functions that the full api adds.

Note that from a quantitative perspective you have 1600 loc of depencency-less ocaml and 1500 that depends on C. But I hadn't the time to see to what kind functionality these 1600 pure lines correspond.

(N.B. I won't mind if you don't use this).

[rleonid]

@dbuenzli I'm closing this as your commits are integrated into #174 which will most likely go through. Thank you!