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ó: > > 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 – 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