caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: David Teller <David.Teller@univ-orleans.fr>
To: "Daniel Bünzli" <daniel.buenzli@erratique.ch>
Cc: OCaml List <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Date: Tue, 18 Nov 2008 15:46:02 +0100	[thread overview]
Message-ID: <1227019562.6170.144.camel@Blefuscu> (raw)
In-Reply-To: <6DE1668B-06D3-4EC7-8B59-0996B814C58B@erratique.ch>

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. 


  reply	other threads:[~2008-11-18 14:46 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-18  9:56 David Teller
2008-11-18 10:06 ` [Caml-list] " Richard Jones
2008-11-18 10:21   ` Zheng Li
2008-11-18 11:22     ` David Teller
2008-11-18 12:52       ` Zheng Li
2008-11-18 14:10       ` [Caml-list] " Alain Frisch
2008-11-18 14:19         ` David Teller
2008-11-19  3:06         ` Yaron Minsky
2008-11-19  3:47           ` Till Varoquaux
2008-11-19 10:57           ` Stefano Zacchiroli
2008-11-19 18:05             ` Stéphane Glondu
2008-11-20  0:14               ` Stefano Zacchiroli
2008-11-18 10:29   ` [Caml-list] " Erkki Seppala
2008-11-18 11:34     ` Daniel Bünzli
2008-11-18 11:47       ` Thomas Gazagnaire
2008-11-18 12:15       ` David Teller
2008-11-18 12:32         ` Richard Jones
2008-11-18 12:56           ` David Teller
2008-11-19 13:38           ` Stefano Zacchiroli
2008-11-19 17:37             ` Richard Jones
2008-11-23 10:32               ` Stefano Zacchiroli
     [not found]         ` <9b415f950811180428x2de94a64q6fa92887f8e00705@mail.gmail.com>
2008-11-18 12:51           ` David Teller
2008-12-19 11:00             ` Benedikt Grundmann
2009-01-05 10:40               ` David Teller
2008-11-18 13:24         ` Daniel Bünzli
2008-11-18 14:46           ` David Teller [this message]
2008-11-18 12:40       ` David Teller
2008-11-18 13:31         ` Dario Teixeira
2008-11-18 14:23           ` David Teller
2008-11-18 14:40             ` Stefano Zacchiroli
2008-11-19 13:36       ` Stefano Zacchiroli
2008-11-19 14:28         ` Daniel Bünzli
2008-11-19 14:45           ` Paolo Donadeo
2008-11-21 12:37     ` Michaël Le Barbier
2008-11-18 11:17   ` David Teller
2008-11-18 12:22     ` Richard Jones
2008-11-18 12:49       ` David Teller
2008-11-18 15:20         ` Richard Jones
2008-11-18 18:17   ` Jon Harrop
2008-11-18 17:51     ` Nicolas Pouillard
2008-11-18 22:43       ` Jon Harrop
2008-11-18 18:59     ` Richard Jones
2008-11-18 20:17       ` Jon Harrop
2008-11-18 19:22         ` Richard Jones
2008-11-18 19:50           ` Daniel Bünzli
2008-11-18 21:50             ` Richard Jones
2008-11-19 13:48               ` Stefano Zacchiroli
2008-11-19 19:02                 ` Stéphane Glondu
2008-11-18 22:07     ` Alain Frisch
2008-11-18 23:49       ` Jon Harrop
2008-11-18 23:13         ` Alain Frisch
2008-11-19 13:28   ` Stefano Zacchiroli
2008-11-18 23:30 ` Jon Harrop
2008-11-19  6:29   ` David Teller
2008-11-19  8:36     ` Jon Harrop
2008-11-19  9:46     ` Paolo Donadeo
2008-11-19 20:11       ` Maxence Guesdon
2008-11-20  9:28         ` Nicolas Pouillard
2008-11-20 10:33           ` Richard Jones
2008-11-20 10:49             ` open Module (not?) considered harmful Stefano Zacchiroli
2008-11-20 11:29               ` [Caml-list] " David Allsopp
2008-11-20 11:48                 ` Richard Jones
2008-11-20 17:56                   ` Stefano Zacchiroli
2008-11-20 13:01                 ` Nicolas Pouillard
2008-11-20 13:41                   ` Nicolas Pouillard
2008-11-20 16:44                     ` Stefano Zacchiroli
2008-11-21  2:56                       ` Stability of exceptions Eliot Handelman
2008-11-21  7:39                         ` [Caml-list] " Daniel Bünzli
2008-11-21  9:52                         ` Christophe TROESTLER
2008-11-20 14:46                 ` [Caml-list] open Module (not?) considered harmful Ashish Agarwal
2008-11-20 17:54                 ` Stefano Zacchiroli
2008-11-20 11:31               ` Daniel Bünzli
2008-11-23 10:36                 ` Stefano Zacchiroli
2008-11-20 11:41               ` Richard Jones
2008-11-23 10:38                 ` Stefano Zacchiroli
2008-11-23 11:01                   ` Richard Jones
2008-11-20 12:58             ` [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included Nicolas Pouillard
2008-11-20 21:12 ` David Teller
2008-11-20 23:18   ` Daniel Bünzli
2008-11-21  9:34     ` David Teller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1227019562.6170.144.camel@Blefuscu \
    --to=david.teller@univ-orleans.fr \
    --cc=caml-list@yquem.inria.fr \
    --cc=daniel.buenzli@erratique.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).