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

[Ivan Gotovchits <ivg@ieee.org>]

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

>
> - 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 <antronbachin@gmail.com> 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 <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
>
> 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
>
>
>
>

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