Re: [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included

[David Teller <David.Teller@univ-orleans.fr>]

On Fri, 2008-11-21 at 00:18 +0100, Daniel Bünzli wrote:
> 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 ?

No, it's not. You cannot ask everyone to regenerate all the
documentation of every single package they have as often as they install
new packages. The problem is linking already-generated documentation
post-facto.

> > Batteries (pack)
> >     1. Standard (automatically opened)
> 
> Is this Pervasives ? If it is I think the latter name is more  
> descriptive.

It is the replacement for [Pervasives], indeed. And I'm pretty sure
that, for beginners, [Pervasives] is more confusing than [Standard].
Since it's automatically opened anyway, most people won't need to know
the name.

> >     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 ?

Well, that was my argument for hierarchies. Stop stealing my
arguments :)

More seriously, sure.

> > 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.

Well, I've started working on a new generation of documentation
generation should make navigation by topics feasible. I'll try and have
a prototype within 1-2 weeks.

> Best,
> 
> Daniel

Cheers,
 David
-- 
David Teller-Rajchenbach
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations.