From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 10226BBAF for ; Fri, 21 Nov 2008 10:34:31 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIBAC8PJknCpx6vi2dsb2JhbACTWQEBAQoLChi/PYJ8 X-IronPort-AV: E=Sophos;i="4.33,639,1220220000"; d="scan'208";a="19408142" Received: from discorde.inria.fr ([192.93.2.38]) by mail3-smtp-sop.national.inria.fr with ESMTP; 21 Nov 2008 10:34:30 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id mAL9YUNt022451 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 21 Nov 2008 10:34:30 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIBAC8PJknCpx6vi2dsb2JhbACTWQEBAQoLChi/PYJ8 X-IronPort-AV: E=Sophos;i="4.33,639,1220220000"; d="scan'208";a="19408141" Received: from smtpka.univ-orleans.fr (HELO ka.univ-orleans.fr) ([194.167.30.175]) by mail3-smtp-sop.national.inria.fr with ESMTP; 21 Nov 2008 10:34:29 +0100 Received: from smtps.univ-orleans.fr (localhost [127.0.0.1]) by ka.univ-orleans.fr (Postfix) with ESMTP id ECE1512AD42; Fri, 21 Nov 2008 10:34:29 +0100 (CET) Received: from [192.168.0.12] (ras75-4-82-235-58-110.fbx.proxad.net [82.235.58.110]) by smtps.univ-orleans.fr (Postfix) with ESMTP id 8833836E60; Fri, 21 Nov 2008 10:34:30 +0100 (CET) Subject: Re: [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included From: David Teller To: Daniel =?ISO-8859-1?Q?B=FCnzli?= Cc: OCaml In-Reply-To: <8FC320CA-074E-48B9-9FB5-CEEB617D7C7D@erratique.ch> References: <1227002178.6170.25.camel@Blefuscu> <1227215540.7676.23.camel@Blefuscu> <8FC320CA-074E-48B9-9FB5-CEEB617D7C7D@erratique.ch> Content-Type: text/plain; charset=utf-8 Date: Fri, 21 Nov 2008 10:34:34 +0100 Message-Id: <1227260074.6486.15.camel@Blefuscu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 8bit X-Miltered: at discorde with ID 492680A6.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 univ-orleans:01 0100,:01 pervasives:01 pervasives:01 semantically:01 functorize:01 toplevel:01 cheers:01 univ-orleans:01 lifo:01 13.:98 19.:98 liquidations:98 threads:01 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.