From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p9QCVVV9020226 for ; Wed, 26 Oct 2011 14:31:31 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIBAFX8p07U4xEIkWdsb2JhbABChHWiAYJDIgEBAQEJCwsHFAMigW4BAQQBI1YFCwsYAgImAgJXGQkLAQaHZQIGokCSK4EwhiaBFASMUIxnjDQ X-IronPort-AV: E=Sophos;i="4.69,409,1315173600"; d="scan'208";a="126089308" Received: from moutng.kundenserver.de ([212.227.17.8]) by mail1-smtp-roc.national.inria.fr with ESMTP; 26 Oct 2011 14:31:25 +0200 Received: from office1.lan.sumadev.de (dslb-188-097-074-151.pools.arcor-ip.net [188.97.74.151]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0Lt8oh-1QtlnK1Mhn-012rkX; Wed, 26 Oct 2011 14:31:25 +0200 Received: from [192.168.5.106] (dslb-188-097-074-151.pools.arcor-ip.net [188.97.74.151]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 12937C00C7; Wed, 26 Oct 2011 14:31:25 +0200 (CEST) From: Gerd Stolpmann To: yminsky@gmail.com Cc: caml-list@inria.fr In-Reply-To: References: <1319614400.18639.148.camel@thinkpad> Content-Type: text/plain; charset="UTF-8" Date: Wed, 26 Oct 2011 14:31:24 +0200 Message-ID: <1319632284.18639.181.camel@thinkpad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:ingX+Cg7cSJ2SCPtDN1Ko/EM+P+r7zE7hF6CdAFPzug IyztX2As4nFtiiaBmAop7Q2AetEzBGZILv5M8okQttvz625xGu oPop7h0dPO67lzs8aXghlH8UTn/27clZ6iK3dyFB6zcT1g8FQo 3wNuJ+28q4Y5OpeRni8P60QjUwMdkXDD92d/QZ62+gLoGFi2dF RA0dJ6hN9H5l5JiOHBGbLmga7Arc9EBif37Ll5ytX4SUUrQs7I MS6YJCAjLtBrpIeuCpjRkhSGbL9E4Q6kcJ8FGfjWkfoPDeq93m JTReV/Wc8QeF8bAQrjO+Em+CG9r0IMxvfFFND3fcQboJaOuJS1 HUTUx844Zm7XhAJlLOGWkD8b78D5v3KOUGhyY0hND Subject: Re: [Caml-list] [ANN] Async, a monadic concurrency library Am Mittwoch, den 26.10.2011, 06:57 -0400 schrieb Yaron Minsky: > I admit to a certain amount of ambivalence to releasing Yet Another > Monadic Concurrency library. (I don't think Equeue is in quite the > same category, since it has such a different style of interface.) Equeue offers several styles. On the lower level it is quite different, but the version offered by the Uq_engines module is pretty much the same with its own naming style (e.g. seq instead of bind etc.). > But I think we had good reasons for creating Async. As I said in my > blog post, the differences in error-handling and interleaving policy > were enough that we really felt we needed a different library. In deed this is interesting. Equeue also follows Lwt's idea not to interleave when possible, simply for performance reasons. You can, however, demand at any time to interleave (with the eps_e operator), and a user wanting this always could build a little layer on top of Equeue to force it. Exceptions are specially represented in Equeue as a different kind of return value. Most operators catch exceptions, cancel the remaining part of the execution flow (which is also specially supported, simulating a "falling through" effect), and return the exception. Effectively, this means that exceptions do not need that much attention, and often the right thing is done anyway. > And now that we've created it, there are multiple reasons to release > it. For one thing, we want it for out own open-source projects > outside of the office! And it's a precondition for us for releasing > other software that we've developed internally that depends on Async. Honestly, I'm a bit concerned about the yet-another-async library, because a library writer can usually only support one library, and remains incompatible with the other ones. What would you do if you wanted to use NetAMQP, which is for Equeue? It would be complicated (and maybe even impossible) to integrate this library into a program using Async otherwise. For Equeue+Lwt in the same program there is now at least a partial solution, but it is not really pleasant. What I fear is that the community is split up into fractions. The community is not so large that we can afford this. > As an aside, we use lots of OCaml libraries developed outside our > walls: RES, PCRE, Lacaml, Postgres bindings and OUnit and xml-light, > to name some off the top of my head. Where some of the developers happen to be Jane Street employees... Seriously, in many companies there is a culture to block everything from outside, and that's the other half of my concerns. Not that all this means you shouldn't publish your code. It's great but certainly not substituting community interaction. Gerd > > > y > > > On Wed, Oct 26, 2011 at 3:33 AM, Gerd Stolpmann > wrote: > Which is already the third one (Equeue and Lwt being the > others). I'm > very up to reinventing the wheel, but I guess there is some > reason. > > Does Janestreet use any open source libraries? Or does the > commitment > not go that far? > > Gerd > > Am Dienstag, den 25.10.2011, 20:32 -0400 schrieb Yaron Minsky: > > > While we're in the announcing mood, I wanted to announce the > first > > public release of Async, Jane Street's monadic concurrency > library. > > > > You can find out more about Async here: > > > > > > http://ocaml.janestreet.com/?q=node/100 > > > > > > y > > > -- > ------------------------------------------------------------ > Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de > Creator of GODI and camlcity.org. > Contact details: http://www.camlcity.org/contact.html > Company homepage: http://www.gerd-stolpmann.de > *** Searching for new projects! Need consulting for system > *** programming in Ocaml? Gerd Stolpmann can help you. > ------------------------------------------------------------ > > > -- ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de *** Searching for new projects! Need consulting for system *** programming in Ocaml? Gerd Stolpmann can help you. ------------------------------------------------------------