Re: [Caml-list] [ANN] Lwt 2.7.0 – monadic promises; concurrent I/O

[Anton Bachin <antronbachin@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6825 bytes --]

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 <ivg@ieee.org> escribió:
> 
> 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 <https://github.com/BinaryAnalysisPlatform/bap/blob/master/lib/bap_future/bap_future.mli>
> 
> On Fri, Jan 6, 2017 at 11:08 AM, Anton Bachin <antronbachin@gmail.com <mailto:antronbachin@gmail.com>> wrote:
> Greetings,
> 
> I am pleased to announce release 2.7.0 of Lwt.
> 
>   https://github.com/ocsigen/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 <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 – if it is, you will be notified. You may, however,
> 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 <https://github.com/ocsigen/lwt/issues/308>
> [2]: https://github.com/ocsigen/lwt/issues/293 <https://github.com/ocsigen/lwt/issues/293>
> [3]: https://github.com/ocsigen/lwt/issues/309 <https://github.com/ocsigen/lwt/issues/309>
> [4]: http://semver.org/ <http://semver.org/>
> [5]: https://github.com/ocsigen/lwt/releases/tag/2.7.0 <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 <https://sympa.inria.fr/sympa/arc/caml-list>
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners <http://groups.yahoo.com/group/ocaml_beginners>
> Bug reports: http://caml.inria.fr/bin/caml-bugs <http://caml.inria.fr/bin/caml-bugs>


[-- Attachment #2: Type: text/html, Size: 10790 bytes --]