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 9817D800BE for ; Fri, 6 Jan 2017 21:36:51 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=ivg@ieee.org; spf=Pass smtp.mailfrom=ivg@ieee.org; spf=None smtp.helo=postmaster@mail-lf0-f43.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of ivg@ieee.org) identity=pra; client-ip=209.85.215.43; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="ivg@ieee.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of ivg@ieee.org designates 209.85.215.43 as permitted sender) identity=mailfrom; client-ip=209.85.215.43; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="ivg@ieee.org"; 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-lf0-f43.google.com) identity=helo; client-ip=209.85.215.43; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="postmaster@mail-lf0-f43.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AiLRDlRKHr7gMna/DZ9mcpTZWNBhigK39O0sv0rFi?= =?us-ascii?q?tYgeLf7xwZ3uMQTl6Ol3ixeRBMOAuq4C0bOd6vu+EUU7or+5+EgYd5JNUxJXwe?= =?us-ascii?q?43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRp?= =?us-ascii?q?OOv1BpTSj8Oq3Oyu5pHfeQtFiT6ybL9oMhm6sArdutQYjIZjN6081gbHrnxUdu?= =?us-ascii?q?pM2GhmP0iTnxHy5sex+J5s7SFdsO8/+sBDTKv3Yb02QaRXAzo6PW814tbrtQTY?= =?us-ascii?q?QguU+nQcSGQWnQFWDAXD8Rr3Q43+sir+tup6xSmaIcj7Rq06VDi+86tmTgLjhT?= =?us-ascii?q?wZPDAl7m7Yls1wjLpaoB2/oRx/35XUa5yROPZnY6/RYc8WSW9HU8lWSiJBH5i8?= =?us-ascii?q?b5MRAOUdIeZWoY79p14Uohu/AwmnGefjxzBMi3Pz26AxzuYvHhzc3AE4Hd0Ovn?= =?us-ascii?q?Taotv2OqkPT+660LLFwi/fY/5Mwzrx9JTEfxInrPqRXbxwa83RyUw3Gg3GkFWf?= =?us-ascii?q?s4rlNC6U2OQKr2ib6PRgWv6vi24mtwFxuSWky8AtionXiYIY0VHE+jtnz4krP9?= =?us-ascii?q?G4T1R7YdG9HZZWqiqUOYx2QsY4TGFpviY30rwGuZihfCgL0psr3RDfa+aff4iH?= =?us-ascii?q?4xLjSOaRISpji35/ZL2/gBOy/VCgy+LmVsm011FKojBZndnLs3ABzwfT5daCSv?= =?us-ascii?q?tj4EihwyyD1wfJ6uFLJ00/iKnVK4Y5z7IuipYetV7PEyz2lUnskqOaa0Up9vKn?= =?us-ascii?q?5unpZLjtu4WSOJVuig7kN6Qjgsy/Dvo8MggJR2Wb/P6z1Lzn/UHgRLVKgOE6nr?= =?us-ascii?q?DXsJ3VK8kXvKG5AwhS0oYs7xawES2q38gfnXkCNF5FeRSHgJb1O1zWPvz0EfOy?= =?us-ascii?q?j06vnTpr3fzKIKDtD5XXInXMnrrtZbN95FRdyAo3w9Bf/ZVUCrQZLfLyRE/xu8?= =?us-ascii?q?fVDh4nPAOq3enrEtJ91pkRWW6XGK+WLLvSsUOU5uIoO+SDeJUauDP5K/Q84/7u?= =?us-ascii?q?jGQ5mUMGcKmy3ZoXbWi4Ee58L0WYZ3rsmNYBHn0QsgowVuy5wGGFBBdVe3G0F4?= =?us-ascii?q?g17TE6DsryBIHfXIerirWK3Ca9NpJTb2FCTFuLFCG7WZ+DXqItdiuUauBmjjsa?= =?us-ascii?q?XrigV5RpgRCwuyf7xrdqaO3O9XtL5trYyNFp6riLxlkJ/jtuApHYjjiA?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DpAAAT/29YhivXVdFVCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBARQBAQEBAQEBAQEBAQcBAQEBAYMOAQEBAQF+gQwHhEyJBJIigjW?= =?us-ascii?q?FSoU4EII1UIFygmiCCSyFdgKBTwc/FAEBAQEBAQEBAQEBEgEBAQgLCwodMEIOg?= =?us-ascii?q?WMaghsBAQEDASMdAQEsCwEECwsLAwoMAR0CAiEBEgEFAQoHCwYTEgIGiDsDCwU?= =?us-ascii?q?IDqQBP4sbaIIlgwgBAQWEKwMKglYBAQEHAQEBAQEBARkIEoYzg1uBBoJOG4E2V?= =?us-ascii?q?IJbgl6HIgyBWoYSfEiKBDiGWIU1gT6DfIF3UYQ3g0qGEooDhwgUHoEUDxCCAQg?= =?us-ascii?q?1EwSDWikPEQuBfSA1AYVVgxABAQE?= X-IPAS-Result: =?us-ascii?q?A0DpAAAT/29YhivXVdFVCRkBAQEBAQEBAQEBAQcBAQEBARQ?= =?us-ascii?q?BAQEBAQEBAQEBAQcBAQEBAYMOAQEBAQF+gQwHhEyJBJIigjWFSoU4EII1UIFyg?= =?us-ascii?q?miCCSyFdgKBTwc/FAEBAQEBAQEBAQEBEgEBAQgLCwodMEIOgWMaghsBAQEDASM?= =?us-ascii?q?dAQEsCwEECwsLAwoMAR0CAiEBEgEFAQoHCwYTEgIGiDsDCwUIDqQBP4sbaIIlg?= =?us-ascii?q?wgBAQWEKwMKglYBAQEHAQEBAQEBARkIEoYzg1uBBoJOG4E2VIJbgl6HIgyBWoY?= =?us-ascii?q?SfEiKBDiGWIU1gT6DfIF3UYQ3g0qGEooDhwgUHoEUDxCCAQg1EwSDWikPEQuBf?= =?us-ascii?q?SA1AYVVgxABAQE?= X-IronPort-AV: E=Sophos;i="5.33,326,1477954800"; d="scan'208,217";a="207460146" Received: from mail-lf0-f43.google.com ([209.85.215.43]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 06 Jan 2017 21:36:49 +0100 Received: by mail-lf0-f43.google.com with SMTP id m78so39504795lfg.2 for ; Fri, 06 Jan 2017 12:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MQP90vjKoma+JnOrf0jEea489HUo2GvcQXxyzc1weQA=; b=cSIMHOi7AjRZAVHARIvx1EZVJ175rPawuNZe/QvfoxheTZlpxdRXiq/Rm4+c7BMonP HCOp+F4sC+vbE2ldaZX3E7ogA6t9sMDaqPnWGwgMLbQnQ5Ad7P64YcGUqvimimAO8uVo oxvCMfwH96hIQaioAg1BRkW2VmvcBSdZwHG5y93Lg+D0Up6VXbie9jHWb5CmAvkZU4iV CrTU6rhb1XhvNgk8flgL9FWMxaVzcCpiCetx37nS8NkVjkgWFuI1PHcXEhY3Sabcr508 2fMbGP6aqy2Y92bdDRd/Y3rB5y6aUsZo1iOLf3Etb2Vgj6drx/fRPnMVYkFmlRjrfRMc R2MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MQP90vjKoma+JnOrf0jEea489HUo2GvcQXxyzc1weQA=; b=cnc4vUqWLaP01VIMum+5yD2myDMcfujckPyceERfxedx8sd6pH0XSJdm/uplcg7CKv MC6/oOCP+fJZSwpMZW9Stn7o9DNzuoeLjkJ4glrZR6uAYwPJwy/mjF6ftuBHXBDZLGwW fIg6uCcqzj0zI84RN0nYBGJg3bGZYE2Qxz9eYLJ9bEpiOaL2u7G9lhKGCMMpPoM2NjVi GNabrqOrvoyLGBKY1YG1ZDSPUeVoP3QXRl1RdzCnopKvn8/9L8oeu4MfBvNMq0Y7vcQP 1xcfoElUKfKN/7bIRE0BGNox55nwxrlRduiAsTOxkByT+SRxYMN/XaDrnIyF9AwKcX8J RC6Q== X-Gm-Message-State: AIkVDXLSttATmGUxHZmMvZVCp3YlncRLoNkxaEquDqr1yiwjfucf9WwZMPw2pBfjmuPPj7V3WDEguBIdbRI8kx5L X-Received: by 10.25.72.215 with SMTP id v206mr28215411lfa.12.1483735008494; Fri, 06 Jan 2017 12:36:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.93.99 with HTTP; Fri, 6 Jan 2017 12:36:47 -0800 (PST) In-Reply-To: <3E0A0A1C-BEEE-464C-907E-663038F0DAF6@gmail.com> References: <22A97EAF-DBFF-4FE8-90C3-0343533CC621@gmail.com> <3E0A0A1C-BEEE-464C-907E-663038F0DAF6@gmail.com> From: Ivan Gotovchits Date: Fri, 6 Jan 2017 15:36:47 -0500 Message-ID: To: Anton Bachin Cc: "caml-list@inria.fr users" Content-Type: multipart/alternative; boundary=94eb2c1a1f5e1f6b74054572fa66 Subject: Re: [Caml-list] =?UTF-8?Q?=5BANN=5D_Lwt_2=2E7=2E0_=E2=80=93_monad?= =?UTF-8?Q?ic_promises=3B_concurrent_I/O?= --94eb2c1a1f5e1f6b74054572fa66 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > - The term promise is used in JavaScript. > - A large number of programmers use JavaScript. These are very strong arguments. Yeah, JS didn't form my worldview (thank god). But, I totally agree with you that if we will forget the C++, then "promise" is a perfectly fine word for describing Lwt thread values. But please still consider adding a small comment about the terminology ambiguity as a tribute for the C++ background :) As you may see, we can get confused)) I also like the resolver :) It is non-ambiguous (you can't confuse promise and resolver, that's nice). On Fri, Jan 6, 2017 at 2:41 PM, Anton Bachin wrote: > Ivan, > > I personally would have preferred to call them futures. I actually come > from a C++ background, including modern C++, and also I just like the > word "future" more than "promise." > > However, I read through some articles, blogs, and SO posts, and came > away with the impression that the terminology is really not settled > between languages. Given that, I chose "promise" and "resolver" with the > following reasoning: > > - The term promise is used in JavaScript. > - A large number of programmers use JavaScript. > - Lwt compiles to JavaScript sometimes. > - We may want to give special support for interfacing between Lwt and > JavaScript promises one day [1]. > - Presumably, the people who standardized on "promise" in JavaScript had > good reasons for doing so, which I don't have time to deeply > investigate at the moment. While it is true that C++, among other > communities, standardized on different terminology, and also had good > reasons for doing so, the JavaScript precedent suggests that "promise" > is somehow defensible. I am "calling" on this precedent as an opaque > "library" of argument and experience. This may be a mistake :) > - I believe, during their process, JavaScript eventually explicitly > rejected > both terms "future" and "deferred." > - "resolver" is just what I was left with after assigning "promise" to > what I thought should be "future" :) > > The work-in-progress manual uses these terms. > > It is possible to change the terminology, with suitable arguments. The > terminology issue is in GitHub [2]. > > Best, > Anton > > > [1]: https://github.com/ocsigen/lwt/issues/270 > [2]: https://github.com/ocsigen/lwt/issues/300 > > > El ene 6, 2017, a las 12:00, Ivan Gotovchits escribi=C3=B3: > > These are the great news! > > And thanks for the maintainers notification, it was really helpful :) > > I have one comment, though: > > > >> Values of types 'a Lwt.t are now called promises rather than threads. >> This should eliminate a lot of confusion for beginners. > > > And create a confusion for seasoned programmers, especially for those who > are accustomed to > C++ newly introduced concepts, like promises and futures, where a promise > has quite an opposite > meaning. In short, it has the same meaning as a value of type `'a > Lwt.u`, i.e., it is an object through > which a promise can be fulfilled. I think that it is better to refer to > Lwt.t threads as futures because they > are the values, whose value is determined in the future. Another way to > name them is `deferred`, again > for the same reason. You can also say, that a value of type `'a Lwt.t` is > a computation. You can also try > to borrow names from the Standard ML community, where `'a Lwt.t` like > objects are named as IVars. > > Finally, you may also find this project interesting [1]. This is an > attempt to factor out the core idea from both > Core Async and Lwt. In particular, the Future library allows us to write a > monadic code, that is independent > of a particular implementation (Lwt or Async or Identity monad). > > [1]: https://github.com/BinaryAnalysisPlatform/bap/ > blob/master/lib/bap_future/bap_future.mli > > On Fri, Jan 6, 2017 at 11:08 AM, Anton Bachin > wrote: > >> Greetings, >> >> I am pleased to announce release 2.7.0 of Lwt. >> >> https://github.com/ocsigen/lwt >> >> The primary goals of this release are (1) to improve communication >> between maintainers and users, and (2) to prepare for (minor) breaking >> changes to some APIs in Lwt 3.0.0 (planned for April). The changelog is >> available here: >> >> https://github.com/ocsigen/lwt/releases/tag/2.7.0 >> >> - Lwt now uses deprecation warnings ([@deprecated]), especially for >> upcoming breaking changes [1]. This required dropping support for >> OCaml 4.01. >> - There is a gradual, communicative, conservative process for >> deprecation and breaking [2]. Maintainers of packages in OPAM get >> notified proactively (see [1] again). If you have code not published >> in OPAM, watch the Lwt repo, recompile the code at least once in three >> months, watch this mailing list, or subscribe to the Lwt announcements >> issue [3]. >> - If a planned breaking change is a bad idea, please let the maintainers >> know when you see the warning. >> - Lwt now uses semantic versioning [4]. The major version will grow >> slowly but steadily, but this does not mean that the whole API is >> being redesigned or broken. >> >> If you are releasing a package to OPAM that depends on Lwt, it is not >> recommended to constrain Lwt to its current major version. A major >> release of Lwt will break only a few APIs, and your package is likely >> not to be affected =E2=80=93 if it is, you will be notified. You may, ho= wever, >> wish to constrain Lwt to a major version in your private or production >> code. >> >> - The main OPAM package lwt is getting rid of some optional >> dependencies in 3.0.0, which are now installable through separate OPAM >> packages lwt_ssl, lwt_glib, lwt_react. This is to reduce recompilation >> of Lwt when installing OPAM packages ssl, lablgtk, and react. >> - Values of types 'a Lwt.t are now called promises rather than threads. >> This should eliminate a lot of confusion for beginners. >> >> Lwt 2.7.0 also has a number of more ordinary changes, such as bug fixes >> and the addition of bindings to writev and readv. See the full >> changelog [5]. >> >> I am working on an all-new manual, including fully rewritten API >> documentation with examples. It should be ready towards the end of >> winter. >> >> My hope is that all the above allows Lwt to be taken progressively into >> the future, at the same time making development more open and more >> humane :) >> >> Best, >> Anton >> >> >> [1]: https://github.com/ocsigen/lwt/issues/308 >> [2]: https://github.com/ocsigen/lwt/issues/293 >> [3]: https://github.com/ocsigen/lwt/issues/309 >> [4]: http://semver.org/ >> [5]: https://github.com/ocsigen/lwt/releases/tag/2.7.0 >> >> >> -- >> 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 > > > > --94eb2c1a1f5e1f6b74054572fa66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
- The te= rm promise is used in JavaScript.
- A large number of programmers use Ja= vaScript.

These are very strong arguments. = Yeah, JS didn't form my worldview (thank=C2=A0god).=C2=A0 But, I totall= y agree with you
that if we will forget the C++, then "promi= se" is a perfectly fine word for describing Lwt=C2=A0thread values. Bu= t please
still consider adding a small comment about the terminol= ogy ambiguity as a tribute for the C++ background :) As=C2=A0
you= may see, we can get confused))

I also like the re= solver :) It is non-ambiguous=C2=A0(you can't confuse promise and resol= ver, that's nice).=C2=A0

On Fri, Jan 6, 2017 at 2:41 PM, Anton Bachin <= antronbachin@gmail.com> wrote:
Ivan,

I personally would have preferred to call them futures. I actually co= me
from a C++ background, including modern C++, and also I just l= ike the
word "future" more than "promise."

However, I read through some articles, blogs, and SO= posts, and came
away with the impression that the terminology is= really not settled
between languages. Given that, I chose "= promise" and "resolver" with the
following reasoni= ng:

- The term promise is used in JavaScript.
- A large number of programmers use JavaScript.
- Lwt compi= les to JavaScript sometimes.
- We may want to give special suppor= t for interfacing between Lwt and
=C2=A0 JavaScript promises one = day [1].
- Presumably, the people who standardized on "promi= se" in JavaScript had
=C2=A0 good reasons for doing so, whic= h I don't have time to deeply
=C2=A0 investigate at the momen= t. While it is true that C++, among other
=C2=A0 communities, sta= ndardized on different terminology, and also had good
=C2=A0 reas= ons for doing so, the JavaScript precedent suggests that "promise"= ;
=C2=A0 is somehow defensible. I am "calling" on this = precedent as an opaque
=C2=A0 "library" of argument and= experience. This may be a mistake :)
- I believe, during their p= rocess, JavaScript eventually explicitly rejected
=C2=A0 both ter= ms "future" and "deferred."
- "resolver&= quot; is just what I was left with after assigning "promise" to
=C2=A0 what I thought should be "future" :)
The work-in-progress manual uses these terms.

It is possible to change the terminology, with suitable arguments.= The
terminology issue is in GitHub [2].

Best,
Anton




El ene 6, 2017, a las 12:00, Iva= n Gotovchits <ivg@ieee= .org> escribi=C3=B3:

These are the great news!=C2= =A0

And thanks for the maintainers=C2=A0notificati= on, it was really helpful :)

I have one comment, t= hough:

=C2=A0
Values of types 'a Lwt.t are now called promises rat= her than threads.
=C2=A0 This should eliminate a lot of confusion for be= ginners.

And create a confusion for seasone= d programmers, especially for those who are accustomed to=C2=A0
C= ++ newly introduced concepts, like promises and futures, where a promise ha= s quite an=C2=A0opposite
meaning.=C2=A0 In short, it has the same= meaning as a value of type =C2=A0`'a Lwt.u`, i.e., it is an object thr= ough
which a promise can be fulfilled. I think that it is bet= ter to refer to Lwt.t threads as futures=C2=A0because they
are th= e values, whose value is determined in the future. Another way to name them= is `deferred`, again
for the same reason. You can also say, that= a value of type `'a Lwt.t` is a computation. You can also try
to borrow names from the Standard ML community, where `'a Lwt.t` like= objects are named as IVars.

Finally, you may also= find this project interesting [1]. This is an attempt=C2=A0to factor out t= he core idea from both
Core Async and Lwt. In particular, the Fut= ure library allows us to write a monadic code, that is independent
of a particular implementation (Lwt=C2=A0or Async or Identity monad). =C2= =A0


On Fri, Jan 6, 2017 at 11:08 AM, Anton Bac= hin <antronbachin@gmail.com> wrote:
Greetings,

I am pleased to announce release 2.7.0 of Lwt.

=C2=A0 https://github.com/ocsigen/lwt

The primary goals of this release are (1) to improve communication
between maintainers and users, and (2) to prepare for (minor) breaking
changes to some APIs in Lwt 3.0.0 (planned for April). The changelog is
available here:

=C2=A0 https://github.com/ocsigen/lwt/releases= /tag/2.7.0

- Lwt now uses deprecation warnings ([@deprecated]), especially for
=C2=A0 upcoming breaking changes [1]. This required dropping support for
=C2=A0 OCaml 4.01.
- There is a gradual, communicative, conservative process for
=C2=A0 deprecation and breaking [2]. Maintainers of packages in OPAM get
=C2=A0 notified proactively (see [1] again). If you have code not published=
=C2=A0 in OPAM, watch the Lwt repo, recompile the code at least once in thr= ee
=C2=A0 months, watch this mailing list, or subscribe to the Lwt announcemen= ts
=C2=A0 issue [3].
- If a planned breaking change is a bad idea, please let the maintainers
=C2=A0 know when you see the warning.
- Lwt now uses semantic versioning [4]. The major version will grow
=C2=A0 slowly but steadily, but this does not mean that the whole API is
=C2=A0 being redesigned or broken.

If you are releasing a package to OPAM that depends on Lwt, it is not
recommended to constrain Lwt to its current major version. A major
release of Lwt will break only a few APIs, and your package is likely
not to be affected =E2=80=93 if it is, you will be notified. You may, howev= er,
wish to constrain Lwt to a major version in your private or production
code.

- The main OPAM package lwt is getting rid of some optional
=C2=A0 dependencies in 3.0.0, which are now installable through separate OP= AM
=C2=A0 packages lwt_ssl, lwt_glib, lwt_react. This is to reduce recompilati= on
=C2=A0 of Lwt when installing OPAM packages ssl, lablgtk, and react.
- Values of types 'a Lwt.t are now called promises rather than threads.=
=C2=A0 This should eliminate a lot of confusion for beginners.

Lwt 2.7.0 also has a number of more ordinary changes, such as bug fixes
and the addition of bindings to writev and readv. See the full
changelog [5].

I am working on an all-new manual, including fully rewritten API
documentation with examples. It should be ready towards the end of
winter.

My hope is that all the above allows Lwt to be taken progressively into
the future, at the same time making development more open and more
humane :)

Best,
Anton


[1]: https://github.com/ocsigen/lwt/issues/308
[2]: https://github.com/ocsigen/lwt/issues/293
[3]: https://github.com/ocsigen/lwt/issues/309
[4]: ht= tp://semver.org/
[5]: https://github.com/ocsigen/lwt/releases/t= ag/2.7.0


--
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



--94eb2c1a1f5e1f6b74054572fa66--