Version française
Home     About     Download     Resources     Contact us    
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: -- (:)
From: David Teller <David.Teller@u...>
Subject: Re: [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, 2008-11-18 at 14:24 +0100, Daniel Bünzli wrote:
> Le 18 nov. 08 à 13:15, David Teller a écrit :
> 
> > But, to keep things ordered, we will still need modules
> > [Threads.Threads], [Threads.Mutex], [Threads.RMutex]...
> > [CoThreads.Threads], [CoThreads.Mutex]... and, well, that's a  
> > hierarchy
> > already.
> 
> If you include in batteries an external package that has its own  
> hierarchy and is designed to be opened I don't mind having that  
> hierarchy.
>
> In that case you can just add the new toplevel entry  
> CoThread. And if I want to use CoThread, I just open CoThreads, not  
> Control.Concurrency.CoThreads. Just try to keep it as flat as  
> possible, don't try to force modules in an ad-hoc hierarchical  
> taxonomy to try to sort out modules. I don't care if the toplevel list  
> of modules is three hundred pages long if there is an efficient mean  
> to access their documentation (like tags). I do however care a lot if  
> it becomes bureaucratic to be able to _use_ a module in my code.

I concur that tags make a considerable difference.

But let us return to threads for one second. There is a very good reason
to have two distinct modules [Threads] and [CoThreads] with 4-5
submodules each: functors. Assuming [Threads] and [CoThreads] implement
the same interface -- which they do -- I can write a module which takes
as argument either [Threads], [CoThreads] or [WhateverThreads] and
produces a pseudo-concurrent/truly concurrent/whatever implementation of
an algorithm. The same thing could apply to latin-1 strings vs. Unicode
strings (this is essentially what happens in Camomile).

Now, there are certainly several possibilities. 

Here's one which doesn't involve a deep hierarchy:
* [Thread], [Mutex], [Concurrent], [Event] remain top-level modules
* [Threads] is also a top-level module, which contains aliases to
[Thread], [Mutex], [Concurrent], [Event]
* [CoThreads] is also a top-level module, which contains its own
implementations of [Thread], [Mutex], [Concurrent], [Event]


We could do the same for strings
* [String], [Char], [Rope], [UChar] remain top-level modules
* we introduce a new module [Strings] containing [String] and [Char]
* we introduce another new module [UStrings] containing an alias
[String] to [Rope] and an alias [Char] to [UChar]

And for numbers
* [Float], [Int], [SafeInt], [BigInt] and hypothetical [SafeFloat] and
[BigFloat] (don't ask me what a BigFloat is supposed to be) remain
top-level modules
* we introduce a new module [Numeric] containing [Float] and [Int]
* we introduce a new module [SafeNumeric] containing [SafeFloat] aliased
as [Float], [SafeInt] aliased as [Int]
* we introduce a new module [BigNumeric] containing [BigFloat] aliased
as [Float], [BigInt] aliased as [Int]

etc.

To me, this seems like the only way to combine no hierarchy and
modularity. However, I have the nasty feeling that this is going to end
up messy, cluttered and otherwise both unmaintainable and unusable
(despite tags).

> 
> Le 18 nov. 08 à 13:22, Richard Jones a écrit :
> 
> > Easy - look at CPAN[1].  If you want to scale a project you have to  
> > make decisions that allow a distributed network of people to  
> > cooperate, without needing too much central coordination.
> 
> But (unfortunately, sorry to repeat that) Batteries is not a CPAN like  
> initiative. It aims at giving a library of modules/syntax extensions  
> selected by the library maintainers, as such it is inherently  
> centralized and I don't think that questions (1) or (2) are actually  
> pertinent for the project.

No, we're not CPAN. If someone wishes to build a CPAN, please feel free
to do it. That may actually be easier to do once Batteries 1.0 has
landed. However, Richard's remark remains interesting. So perhaps
redesigning Batteries to have an open namespace structure is a good
idea.

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.