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 D2A69800BE for ; Fri, 6 Jan 2017 20:41:39 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=antronbachin@gmail.com; spf=Pass smtp.mailfrom=antronbachin@gmail.com; spf=None smtp.helo=postmaster@mail-it0-f54.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of antronbachin@gmail.com) identity=pra; client-ip=209.85.214.54; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="antronbachin@gmail.com"; x-sender="antronbachin@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of antronbachin@gmail.com designates 209.85.214.54 as permitted sender) identity=mailfrom; client-ip=209.85.214.54; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="antronbachin@gmail.com"; x-sender="antronbachin@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-it0-f54.google.com) identity=helo; client-ip=209.85.214.54; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="antronbachin@gmail.com"; x-sender="postmaster@mail-it0-f54.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AGqmvZRzxmj+KnxzXCy+O+j09IxM/srCxBDY+r6Qd?= =?us-ascii?q?2uIeIJqq85mqBkHD//Il1AaPBtSHragdwLOM7+jJYi8p2d65qncMcZhBBVcuqP?= =?us-ascii?q?49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6?= =?us-ascii?q?JvjvGo7Vks+7y/2+94fdbghMizexe61+IAi5oQnMqMUbjpZpJ7osxBfOvnZGYf?= =?us-ascii?q?ldy3lyJVKUkRb858Ow84Bm/i9Npf8v9NNOXLvjcaggQrNWEDopM2Yu5M32rhbD?= =?us-ascii?q?VheA5mEdUmoNjBVFBRXO4QzgUZfwtiv6sfd92DWfMMbrQ704RSiu4qF2QxLzli?= =?us-ascii?q?wJKyA2/33WisxojaJUvhShpwBkw4XJZI2ZLedycr/Bcd8fQ2dOWdtfVzFaAoOk?= =?us-ascii?q?cYQAE/YBM+hfr4n4vVQOrB2+DhSoCO7gzjJEg3n71rA43es8CwHLxBAvEN0Tvn?= =?us-ascii?q?rUrtr7OqQcUe6rwqfP1jjMde9a2TLn5YjIbhwso/eBVq9wf8rLzkkvEhvIg0mW?= =?us-ascii?q?qYz5ODOV0PkGvnWB4OV8VeKvimgnoBx2rze1wMcslpPJhoUTyl/f7yp23IY1Jd?= =?us-ascii?q?y+SENgbt6kFYFftyCeN4dsXswiRGRotT88x7Ybt5C7ey0Kx44mxx7Zc/GHco6I?= =?us-ascii?q?4gjiVOmLOzt4imhldKqwhxaz7UigyvD8WdKu3FlWqSpFl8HAt3AX2BzT7ciHTe?= =?us-ascii?q?Fx8Vum2TaKzwzT8f9LIUUqlaXFMZ4t2LkwloAcsUnFAyT4m132gbeIekk4/uWk?= =?us-ascii?q?8efqb7X8qpOCKoN5hRvyP6Qhl8CnH+g1MxQCU3We9Oii27Dv4Uj0T6lLg/Eqjq?= =?us-ascii?q?XUtZPXKt8GqaKlBgJY04Yu6xikADqj39kVkmcLIExAdR2Zi4XkNV/DLfX5APq9?= =?us-ascii?q?g1mhlDFmzO3cMLL7GJXCNH3Dna/hfblj705czxI+zdVF6JJVDrENOfPzWlPtuN?= =?us-ascii?q?DBAB80MwO5z/zoCNV60YMeVmaPDbGDPKzOtl+I4/ojI+iKZIALpDbwM+Yp6+Lq?= =?us-ascii?q?gHMjmlIQfbOl0YUKZH23BPhrI0qUbWLpgtgbEGcKugQ+TPbtiF2HSTNcfXCyX7?= =?us-ascii?q?4m5jE8DoKpFp3MSZytgLyA2ie2BZJWZmVcBVCNFXfkbZmLW/AJaC6KOM9ujiQE?= =?us-ascii?q?VaS9S48mzRyhqBX1y79jLubN/i0YtInj1MRu6u3IlRAy8CR0AN6H32GMSWF0hG?= =?us-ascii?q?IISCUs0KBxu0wugmuEhIlmivoQOttP4O1CUgYmLtaIzvJ1I9H/Vw+Hec2GHgWI?= =?us-ascii?q?WNKjVBg3UtU3i/UHaEZ8HZ32hxbfxS2sCbYel72NLJMx+6PYmXP2IpAumD79yK?= =?us-ascii?q?A9ggx+EYN0Pmq8i/s6qlHe?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DvAAAf8m9YhjbWVdFVCRoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBARYBAQEDAQEBCQEBAYJnJwEBAQEBfoEMjVeSIYI1iwIQgjWCQoJoggk?= =?us-ascii?q?shXYCgVU/FAEBAQEBAQEBAQEBEgEBAQgLCwodMIIzGoIbAQEBAwEjHQEbEgsBA?= =?us-ascii?q?wELBgULAwoMARoDAgIhAhEBBQEKAREGExICBog6AQMQCAENo3s/jAOCAwUBHIM?= =?us-ascii?q?JBYNiChknAwpUggIBAQEBAQEBAwEBAQEBAQEBAQEBFQIGCQEIiDWBWYEGgk4bg?= =?us-ascii?q?TZUglstgjEFhx0MgVqGEnxIhEGFQziGWIU1gT6DfIF3UYQ3gxgyhhKKA4Qpgl8?= =?us-ascii?q?ygRQPEIFHEhtKDwEDggaBWCkPEQuBflQBiGUBAQE?= X-IPAS-Result: =?us-ascii?q?A0DvAAAf8m9YhjbWVdFVCRoBAQEBAgEBAQEIAQEBARYBAQE?= =?us-ascii?q?DAQEBCQEBAYJnJwEBAQEBfoEMjVeSIYI1iwIQgjWCQoJoggkshXYCgVU/FAEBA?= =?us-ascii?q?QEBAQEBAQEBEgEBAQgLCwodMIIzGoIbAQEBAwEjHQEbEgsBAwELBgULAwoMARo?= =?us-ascii?q?DAgIhAhEBBQEKAREGExICBog6AQMQCAENo3s/jAOCAwUBHIMJBYNiChknAwpUg?= =?us-ascii?q?gIBAQEBAQEBAwEBAQEBAQEBAQEBFQIGCQEIiDWBWYEGgk4bgTZUglstgjEFhx0?= =?us-ascii?q?MgVqGEnxIhEGFQziGWIU1gT6DfIF3UYQ3gxgyhhKKA4Qpgl8ygRQPEIFHEhtKD?= =?us-ascii?q?wEDggaBWCkPEQuBflQBiGUBAQE?= X-IronPort-AV: E=Sophos;i="5.33,326,1477954800"; d="scan'208,217";a="207440499" Received: from mail-it0-f54.google.com ([209.85.214.54]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 06 Jan 2017 20:41:37 +0100 Received: by mail-it0-f54.google.com with SMTP id 192so23097641itl.0 for ; Fri, 06 Jan 2017 11:41:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=VOg0FaHQ2amYKiuGUr7393eIwAoTEZp+Wjiwlv1VJ98=; b=mwYGDgQrj5x8oIytZIzseTciAHIg8/HJo1dCaEm/ObN2ZZrV9nGqBzcrCX5Ws197+D 6fIyI7yKfxOvhbWhwEh5bA3tnMzF7P338/U3fXaJfWoXS9A3gqullA6oNzfP9GSCDbUS SKbVUbPeIaEdD7oOcJ46pHChPUGNIi1vkTBZjhV2g13Mbk+agKL5Pt9PvydBZbPslTQf KSVlupspIw6m+901H9bv+cmkGKW0TutD1rW7QckH8fEl04CWvUJNlDRf/KFwWeOV//Vs fUOLzQCQXsZFEXD7S1vonK747RI7SzdyGwTvgqNhe8SQuuk9NsMuQOqMPfaDhrxEgg56 OBOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=VOg0FaHQ2amYKiuGUr7393eIwAoTEZp+Wjiwlv1VJ98=; b=Aw9bOaMLDpnV5LV7tpNKqY/9oEl8VZ9pdsBj+dyNjbpgEKq3QUNg5w1crrkp5QFKJl tEIBQE/NPYoO4uajyhJ5msLalKyVSDXZJn/S0Etn8TM1dicgyhUAZsjwj59S75iwljTh ekSKhQrIKql7XWoYLsQSdR+2LfxY+NaujI64fqOSvBtuMzEXqjrfZhYdk3/14L5Fbj8B KwIVApMnY95He90XLmm3XTRcT/Eh9/EPqysmLYblYzxK9rnYzPeDWEYKX50CRLmjPJxx ivz9I+6fsqdCEKkKgepGYT/7qC+rgjm3UEWh3OgqTNTVJizvQdya7cFKXj0Q98As+fiD ABtA== X-Gm-Message-State: AIkVDXKZ8AvTch6xHgVhdy/K4m6tf65E9nWyaZ1LX2nxVtOgHiuSh3x7JOmxZGwyT4vMMA== X-Received: by 10.36.116.202 with SMTP id o193mr243365itc.96.1483731696602; Fri, 06 Jan 2017 11:41:36 -0800 (PST) Received: from ?IPv6:2601:240:c600:8bd0:65fb:4422:e933:6759? ([2601:240:c600:8bd0:65fb:4422:e933:6759]) by smtp.gmail.com with ESMTPSA id 141sm1900013itl.17.2017.01.06.11.41.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 06 Jan 2017 11:41:35 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_8105CE3C-9084-4388-AF99-1472E8E2D692" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Anton Bachin In-Reply-To: Date: Fri, 6 Jan 2017 13:41:34 -0600 Cc: "caml-list@inria.fr users" X-Mao-Original-Outgoing-Id: 505424494.332359-c28e8f07c2e27d79e46dad0b112749bb Message-Id: <3E0A0A1C-BEEE-464C-907E-663038F0DAF6@gmail.com> References: <22A97EAF-DBFF-4FE8-90C3-0343533CC621@gmail.com> To: Ivan Gotovchits X-Mailer: Apple Mail (2.2070.6) 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?= --Apple-Mail=_8105CE3C-9084-4388-AF99-1472E8E2D692 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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: >=20 > These are the great news!=20 >=20 > And thanks for the maintainers notification, it was really helpful :) >=20 > I have one comment, though: >=20 >=20=20 > Values of types 'a Lwt.t are now called promises rather than threads. > This should eliminate a lot of confusion for beginners. >=20 > And create a confusion for seasoned programmers, especially for those who= are accustomed to=20 > 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 L= wt.t threads as futures because they > are the values, whose value is determined in the future. Another way to n= ame 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 obj= ects are named as IVars. >=20 > Finally, you may also find this project interesting [1]. This is an attem= pt 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).=20=20 >=20 > [1]: https://github.com/BinaryAnalysisPlatform/bap/blob/master/lib/bap_fu= ture/bap_future.mli >=20 > On Fri, Jan 6, 2017 at 11:08 AM, Anton Bachin > wrote: > Greetings, >=20 > I am pleased to announce release 2.7.0 of Lwt. >=20 > https://github.com/ocsigen/lwt >=20 > 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: >=20 > https://github.com/ocsigen/lwt/releases/tag/2.7.0 >=20 > - 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. >=20 > 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, how= ever, > wish to constrain Lwt to a major version in your private or production > code. >=20 > - 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. >=20 > 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]. >=20 > I am working on an all-new manual, including fully rewritten API > documentation with examples. It should be ready towards the end of > winter. >=20 > 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 :) >=20 > Best, > Anton >=20 >=20 > [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 >=20 >=20 > -- > 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 --Apple-Mail=_8105CE3C-9084-4388-AF99-1472E8E2D692 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Ivan,

I personally would have preferred to call them futures. I actually come<= /div>
from a C++ background, including modern C++, and also = I just like the
word "future" more than "promise."

However, I read thro= ugh 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" wi= th 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<= /div>
  good reasons for doing so, which I don't have t= ime to deeply
  investigate at the moment. While = it is true that C++, among other
  communities, s= tandardized on different terminology, and also had good
  reasons for doing so, the JavaScript precedent suggests that "prom= ise"
  is somehow defensible. I am "calling" on t= his precedent as an opaque
  "library" of argumen= t 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 us= es these terms.

I= t 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 <ivg@ieee.org> escribi=C3=B3:

These are the great news! 
=
And thanks for the maintainers no= tification, it was really helpful :)

I have one comment, though:

 
Values of types 'a Lwt.t are now called promises rather t= han 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 conc= epts, 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 i= s 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 rea= son. You can also say, that a value of type `'a Lwt.t` is a computation. Yo= u can also try
to borrow names from the Standard ML co= mmunity, 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 ide= a 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 or Async or Identity = monad).  

[1= ]: https://github.com/BinaryAnalys= isPlatform/bap/blob/master/lib/bap_future/bap_future.mli

On Fri, J= an 6, 2017 at 11:08 AM, Anton Bachin <antronbac= hin@gmail.com> 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 thr= ee
  months, watch this mailing list, or subscribe to the Lwt announcemen= ts
  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, 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
  dependencies in 3.0.0, which are now installable through separate OP= AM
  packages lwt_ssl, lwt_glib, lwt_react. This is to reduce recompilati= on
  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/ar= c/caml-list
Beginner's list: http://groups.yahoo.com/gro= up/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


= --Apple-Mail=_8105CE3C-9084-4388-AF99-1472E8E2D692--