From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 9CE037FF9F for ; Mon, 7 Mar 2016 15:07:03 +0100 (CET) IronPort-PHdr: 9a23:L/Rk+hah7Ptkk0WMt4xnj///LSx+4OfEezUN459isYplN5qZpMy5bnLW6fgltlLVR4KTs6sC0LqJ9fC5EjFbqb+681k8M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLsh7/0q8SYPl4ArQH+SI0xBS3+lR/WuMgSjNkqAYcK4TyNnEF1ff9Lz3hjP1OZkkW0zM6x+Jl+73YY4Kp5pIZoGJ/3dKUgTLFeEC9ucyVsvJWq5i/4UBCX63AAfmITmxtOS0iZvVCpFqv25xD7s+17kAKAIMTwQKt8DS+j6qBtDhTylS4BOiV/qjmP1eR10LIdpwiu8U9R2YnRNbCSKPN7NonUZ9UdVCIVT8FNXilLC5m6aJonAO8IPOIepI748Qhd5SCiDBWhUbu8ggRDgWX7iOhniuk= Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=yotambarnoy@gmail.com; spf=Pass smtp.mailfrom=yotambarnoy@gmail.com; spf=None smtp.helo=postmaster@mail-yw0-f176.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.161.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.161.176 as permitted sender) identity=mailfrom; client-ip=209.85.161.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-yw0-f176.google.com) identity=helo; client-ip=209.85.161.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-yw0-f176.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DKBADXid1WlrChVdFcg1g0bQaoPYFOKpF8IYVuAoEhBzsRAQEBAQEBAQEQAQEBAQcNCQkhL4ItghUBAQMBEhEdARsSCwEDAQsGBQsaHQICIQEBEQEFAQoSBhMSAg6HagEDCggOolSBMT4xizaBaoJXhRkKGScDClGDdgEBAQEBAQQBAQEBAQEBARIBBQoEhgmEPYI9giqCU4E6BYYcDId8iQaFY4YVgXWCLoxMhwyGCxEegQ8PJ4IiChQIgWYeLgGJPAEBAQ X-IPAS-Result: A0DKBADXid1WlrChVdFcg1g0bQaoPYFOKpF8IYVuAoEhBzsRAQEBAQEBAQEQAQEBAQcNCQkhL4ItghUBAQMBEhEdARsSCwEDAQsGBQsaHQICIQEBEQEFAQoSBhMSAg6HagEDCggOolSBMT4xizaBaoJXhRkKGScDClGDdgEBAQEBAQQBAQEBAQEBARIBBQoEhgmEPYI9giqCU4E6BYYcDId8iQaFY4YVgXWCLoxMhwyGCxEegQ8PJ4IiChQIgWYeLgGJPAEBAQ X-IronPort-AV: E=Sophos;i="5.22,551,1449529200"; d="scan'208,217";a="167453072" Received: from mail-yw0-f176.google.com ([209.85.161.176]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 07 Mar 2016 15:07:02 +0100 Received: by mail-yw0-f176.google.com with SMTP id h129so94288123ywb.1 for ; Mon, 07 Mar 2016 06:07:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+/q6Y2D62qY4SGhYr9DQ/8mYR7b3xYVhTiaqYbo3KGc=; b=JvbN9fuKzHTxIfAHNgaJ5+HEQ5QJd+8VxMJ3ROQauO+SZmBVswCqeqDYhXqcFhdeD4 eY7zQ/LXjRrch1C2X1Y6yw0Cplor+XwcY9LCp0eLsC2oIF0bn/Bc/iuxHuCv4jzT5pIu RqB+xmlgUZYocM+GjjQUct+jatkqMRv4BQY1t5/FJGoP4VvpBqGZef4ySkC/eOOa61yD 5dLdXORvP+Mz9vrldMoE2TY1KGTh/8ksEeaYORJNQu7CBJ9YS0ETkmo656FnGKF1h0yD S65T986XWvhDFzNDIU/mj7o85HPiMGwDOK6PhRG2wsiuLLx3FBLmJqPUVzRiCb3pvuv/ kGcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+/q6Y2D62qY4SGhYr9DQ/8mYR7b3xYVhTiaqYbo3KGc=; b=FMgcSlrHuLr6LFDJ+JT+Gfg5LS6jg49DhDi5Wg2sY0oWvYnnHobkhD0x/M3XNCNQoh EZjxomSLQunQkD330mgI2zVIXkgNG/EbH09immScaUeWH8d84vsrjj4hy8dulJOP9l0w CXebDLGxntzlBaHvlCP2BRYYP3Y7oQOcEYl/8Dcy4jDsS67KREcfh63H855gtCFvW5i5 6HjJDnVVe5Y1RBoKhm39IKQ1pV6/4RlhqfDLHSivNYfRynzElUFOSXk+qpZIVZ//w9n7 vVXaL76TeHNQ+JOmINbSziM/K35TjbjJ5191mhJOawL5NNBb1AoidyrJGdx8uMDVym/9 A8fg== X-Gm-Message-State: AD7BkJLDFRd8+V2TgAYF1cp9fc6VZ6+dZX8pQ3FVdlpX2ydpm7bdvcuVdcoYeGufOEBWiOitnh6nbQnTQTN9Cw== X-Received: by 10.129.86.131 with SMTP id k125mr11605399ywb.158.1457359620723; Mon, 07 Mar 2016 06:07:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.13.3 with HTTP; Mon, 7 Mar 2016 06:06:41 -0800 (PST) In-Reply-To: <20160307090859.GF30630@nunchakus.loria.fr> References: <86oaaqahc1.fsf@gmail.com> <20160307090859.GF30630@nunchakus.loria.fr> From: Yotam Barnoy Date: Mon, 7 Mar 2016 09:06:41 -0500 Message-ID: To: Simon Cruanes Cc: Malcolm Matalka , Ocaml Mailing List Content-Type: multipart/alternative; boundary=001a1143312c80d88a052d75fa3f Subject: Re: [Caml-list] Question about Lwt/Async --001a1143312c80d88a052d75fa3f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is there an existing compatibility library functorized over the intersection of Async and Lwt? That would make being compatible with both much easier. On Mon, Mar 7, 2016 at 4:08 AM, Simon Cruanes wrote: > Hi, > > It seems that Lwt is more popular in the community > outside JaneStreet than Async (if only by looking at its reverse > dependencies on opam.ocaml.org). There has been posts about this, for > instance http://rgrinberg.com/blog/2014/12/11/abandoning-async/ . > However, if you're writing a library, it is good taste (if possible) to > parametrize you code over an "IO" monad that will be easy to instantiate > with either Async or Lwt (or the trivial blocking monad where 'a t =3D 'a > and (>>=3D) x f =3D f x) along with the required IO primitives. > > Regarding general utility functions, if they do not perform IO or depend > on (blocking) IO they can be used directly with Async/Lwt (unless they > really take a very long time to complete). > > Le Mon, 07 Mar 2016, Malcolm Matalka a =C3=A9crit : > > Yotam Barnoy writes: > > > Hi all > > > > > > I'm thinking about my next project in OCaml, and I'm wondering how ma= ny > > > users of OCaml currently use Lwt or Async regularly. > > > > > > One of the advantages of OCaml over Haskell (which I'm not crazy > about) is > > > the fact that you don't have to constantly be stuck inside a monad. > > > However, once you want to use these user-level threading libraries, > you're > > > essentially tied to a monad. It also means that the usage of any other > > > monad from Lwt/Async code is out -- OCaml doesn't have the monad > > > transformer infrastructure to layer monads easily as far as I can tell > (am > > > I wrong?). I mean, even in Haskell using Monad Transformers is a pain > (IMO). > > > > > > Also, what happens to general utility functions that aren't rewritten > for > > > Async/Lwt -- as far as I can tell, being in non-monadic code, they wi= ll > > > always starve other threads, since they cannot yield to another > Async/Lwt > > > thread. Is this perception correct? If so, this seems to imply that y= ou > > > either write your code to cooperate within these frameworks and suffer > the > > > monad, or don't, and make it near-impossible for Lwt/Async users to > make > > > use of your code. > > > > > > I would like to get an idea of the usage level of these libraries, as > well > > > as the burden of writing compatible code, any difficulties etc. Also, > I'd > > > like to get a sense of the domains that benefit from these libraries. > Some > > > domains (such as gaming) traditionally involve a continuous main loop, > and > > > would thus only suffer from the additional overhead of queuing in the= se > > > libraries. > > > > > > -Yotam > > > > I mostly use Async. However, I think most usage of Lwt or Async > > requires doing as little as possible in these frameworks and using them > > to orchestrate other functions. For example, I usually try to separate > > parsing of a network protocol from the reading and writing of the bytes. > > > > -- > > Caml-list mailing list. Subscription management and archives: > > https://sympa.inria.fr/sympa/arc/caml-list > > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > > Bug reports: http://caml.inria.fr/bin/caml-bugs > > > -- > Simon Cruanes > > http://weusepgp.info/ > key 49AA62B6, fingerprint 949F EB87 8F06 59C6 D7D3 7D8D 4AC0 1D08 49AA > 62B6 > --001a1143312c80d88a052d75fa3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there an existing compatibility library functorized ove= r the intersection of Async and Lwt? That would make being compatible with = both much easier.

On Mon, Mar 7, 2016 at 4:08 AM, Simon Cruanes <<= a href=3D"mailto:simon.cruanes.2007@m4x.org" target=3D"_blank">simon.cruane= s.2007@m4x.org> wrote:
Hi,<= br>
It seems that Lwt is more popular in the community
outside JaneStreet than Async (if only by looking at its reverse
dependencies on opam.ocaml.org). There has been posts about this, for
instance http://rgrinberg.com/blog/2014/12/11/= abandoning-async/ .
However, if you're writing a library, it is good taste (if possible) to=
parametrize you code over an "IO" monad that will be easy to inst= antiate
with either Async or Lwt (or the trivial blocking monad where 'a t =3D = 'a
and (>>=3D) x f =3D f x) along with the required IO primitives.

Regarding general utility functions, if they do not perform IO or depend
on (blocking) IO they can be used directly with Async/Lwt (unless they
really take a very long time to complete).

Le Mon, 07 Mar 2016, Malcolm Matalka a =C3=A9crit :
> Yotam Barnoy <yotambarnoy@= gmail.com> writes:
> > Hi all
> >
> > I'm thinking about my next project in OCaml, and I'm wond= ering how many
> > users of OCaml currently use Lwt or Async regularly.
> >
> > One of the advantages of OCaml over Haskell (which I'm not cr= azy about) is
> > the fact that you don't have to constantly be stuck inside a = monad.
> > However, once you want to use these user-level threading librarie= s, you're
> > essentially tied to a monad. It also means that the usage of any = other
> > monad from Lwt/Async code is out -- OCaml doesn't have the mo= nad
> > transformer infrastructure to layer monads easily as far as I can= tell (am
> > I wrong?). I mean, even in Haskell using Monad Transformers is a = pain (IMO).
> >
> > Also, what happens to general utility functions that aren't r= ewritten for
> > Async/Lwt -- as far as I can tell, being in non-monadic code, the= y will
> > always starve other threads, since they cannot yield to another A= sync/Lwt
> > thread. Is this perception correct? If so, this seems to imply th= at you
> > either write your code to cooperate within these frameworks and s= uffer the
> > monad, or don't, and make it near-impossible for Lwt/Async us= ers to make
> > use of your code.
> >
> > I would like to get an idea of the usage level of these libraries= , as well
> > as the burden of writing compatible code, any difficulties etc. A= lso, I'd
> > like to get a sense of the domains that benefit from these librar= ies. Some
> > domains (such as gaming) traditionally involve a continuous main = loop, and
> > would thus only suffer from the additional overhead of queuing in= these
> > libraries.
> >
> > -Yotam
>
> I mostly use Async.=C2=A0 However, I think most usage of Lwt or Async<= br> > requires doing as little as possible in these frameworks and using the= m
> to orchestrate other functions.=C2=A0 For example, I usually try to se= parate
> parsing of a network protocol from the reading and writing of the byte= s.
>
> --
> Caml-list mailing list.=C2=A0 Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group= /ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs


--
Simon Cruanes

http= ://weusepgp.info/
key 49AA62B6, fingerprint 949F EB87 8F06 59C6 D7D3=C2=A0 7D8D 4AC0 1D08 49A= A 62B6

--001a1143312c80d88a052d75fa3f--