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=3.2 required=5.0 tests=AWL,DNS_FROM_RFC_POST, SPF_NEUTRAL 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 E0FCFBBAF for ; Fri, 21 Nov 2008 00:19:15 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmICAPZ+JUnAXQImgWdsb2JhbACTGz4BARYisl2LCwEDAQOCeYIQ X-IronPort-AV: E=Sophos;i="4.33,639,1220220000"; d="scan'208";a="19396678" Received: from discorde.inria.fr ([192.93.2.38]) by mail3-smtp-sop.national.inria.fr with ESMTP; 21 Nov 2008 00:19:15 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id mAKNJFKr012074 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 21 Nov 2008 00:19:15 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4AALt+JUlA6ba7imdsb2JhbACTGz4BAQEKCQwHDwWyV4sLAQMBA4J5ghA X-IronPort-AV: E=Sophos;i="4.33,639,1220220000"; d="scan'208";a="20199505" Received: from nf-out-0910.google.com ([64.233.182.187]) by mail1-smtp-roc.national.inria.fr with ESMTP; 21 Nov 2008 00:19:14 +0100 Received: by nf-out-0910.google.com with SMTP id d3so442986nfc.7 for ; Thu, 20 Nov 2008 15:19:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=hACCvtx8NxoJ4l0pdAcCOZGsC/6IvoxkrhFpOKOup5Y=; b=KDCdiM5uwKfAoajcf7q545KJQVwyjcJfRzqqR6a+ZWilUTtO9Ith4s4i4vEX7lPK89 5WysyqRtfEBtIkTfPb6g06+LUCIVHk0BcM1SvZzPF4VXON7jpVkeP0POKWCHkVCAUiFh p8pyBFVgn3ISfPMHb3rMaEaD5arwLtX0jtnCs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=ajcw37ZvihUPeDJMenWMJ8Pk4oMgcNgvnTcHFjzmAWU9LIvZ50oiVUw+CTBAuRTxzF 6z62qFHKzcsp3IDaGV+xR+jixVkgmvaKVhTKPqmBGi0Z1ZW2PiQpLBWeju/kUopsy6B0 0vZ4l1PlJ1KwioIFie3fQwq3dStJxZ+wr/BMw= Received: by 10.86.50.8 with SMTP id x8mr1016815fgx.48.1227223154248; Thu, 20 Nov 2008 15:19:14 -0800 (PST) Received: from ?192.168.1.34? (236-50.76-83.cust.bluewin.ch [83.76.50.236]) by mx.google.com with ESMTPS id l12sm2963776fgb.6.2008.11.20.15.19.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 20 Nov 2008 15:19:13 -0800 (PST) Message-Id: <8FC320CA-074E-48B9-9FB5-CEEB617D7C7D@erratique.ch> From: =?ISO-8859-1?Q?Daniel_B=FCnzli?= To: OCaml In-Reply-To: <1227215540.7676.23.camel@Blefuscu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included Date: Fri, 21 Nov 2008 00:18:10 +0100 References: <1227002178.6170.25.camel@Blefuscu> <1227215540.7676.23.camel@Blefuscu> X-Mailer: Apple Mail (2.929.2) Sender: =?UTF-8?B?RGFuaWVsIELDvG56bGk=?= X-Miltered: at discorde with ID 4925F073.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 ocaml:01 pervasives:01 semantically:01 functorize:01 toplevel:01 13.:98 19.:98 threads:01 threads:01 caml-list:01 modules:02 modules:02 linking:02 Le 20 nov. 08 =E0 22:12, David Teller a =E9crit : > If anyone is willing to work on a solution for linking documentation =20= > from third-party libraries into one transparent source, as suggested =20= > by Richard Jones, please contact me. I'm not sure I understand what you want to acheive. If it is only a =20 documentation issue cannot that be done with ocamldoc's -dump and -=20 load ? > Batteries (pack) > 1. Standard (automatically opened) Is this Pervasives ? If it is I think the latter name is more =20 descriptive. > 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 =20 that your idea of only having everything in Threads and CoThread is =20 better and sufficient (i.e. top-level Condition, CoCondition, etc. =20 should be dropped). Advise the users to open Threads/Cothreads to use =20= the modules (or functorize their code on Concurrency). This allows to =20= quickly switch from one implementation to the other by changing the =20 toplevel open directive. With the current proposal users may be =20 tempted to use Condition directly, and what happens if some have used =20= Condition and others CoCondition in their modules and we suddenly try =20= to use them toghether ? > While I personally find this solution a little clumsier than the =20 > previous hierarchy, ymmv. Of course when you look it as a long list it does, but that's a =20 presentation issue. This proposal is much more convenient to use in =20 your code and that's what eventually matters (at least to me). Thanks =20= for the new proposal. Best, Daniel