Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Wanted: your feedback on the hierarchy of OCaml Batteries Included
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-11-20 (23:19)
From: Daniel_Bünzli <daniel.buenzli@e...>
Subject: Re: [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included

Le 20 nov. 08 à 22:12, David Teller a écrit :

> If anyone is willing to work on a solution for linking documentation  
> from third-party libraries into one transparent source, as suggested  
> by Richard Jones, please contact me.

I'm not sure I understand what you want to acheive. If it is only a  
documentation issue cannot that be done with ocamldoc's -dump and - 
load ?

> Batteries (pack)
>     1. Standard (automatically opened)

Is this Pervasives ? If it is I think the latter name is more  

>     13. Threads (A module containing aliases to Condition, Event...)
>    19. CoThreads (as Threads but with implementations coming from
>        coThreads)

If Threads and CoThreads are really semantically compatible I think  
that your idea of only having everything in Threads and CoThread is  
better and sufficient (i.e. top-level Condition, CoCondition, etc.  
should be dropped). Advise the users to open Threads/Cothreads to use  
the modules (or functorize their code on Concurrency). This allows to  
quickly switch from one implementation to the other by changing the  
toplevel open directive. With the current proposal users may be  
tempted to use Condition directly, and what happens if some have used  
Condition and others CoCondition in their modules and we suddenly try  
to use them toghether ?

> While I personally find this solution a little clumsier than the  
> previous hierarchy, ymmv.

Of course when you look it as a long list it does, but that's a  
presentation issue. This proposal is much more convenient to use in  
your code and that's what eventually matters (at least to me). Thanks  
for the new proposal.