Forgot to mention F# and their asynchronous workflows [1]. These guys did a good job of hiding a monad behind simple ideas.

Basically, they use term "asynchronous computation" for the values of type `'a Lwt.t` 

[1]: https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/asynchronous-workflows

On Fri, Jan 6, 2017 at 1:00 PM, Ivan Gotovchits <ivg@ieee.org> wrote:

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 <antronbachin@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 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
[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