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

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

[Anton Bachin]

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

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

[Ivan Gotovchits]

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

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: 6389 bytes --]

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

[Ivan Gotovchits]

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

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
>
>
>

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

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

[Xavier Van de Woestyne]

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

Excellent work ! Thanks a lot !

2017-01-06 19:12 GMT+01:00 Ivan Gotovchits <ivg@ieee.org>:

> 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
>>
>>
>>
>


-- 
Xavier Van de Woestyne
xavier.vdw@gmail.com - TEL BE : 0474 49 53 83 | TEL FR : 06 73 38 72 84

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

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

[Anton Bachin]

[-- 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 --]

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

[Ivan Gotovchits]

[-- 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 --]

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

[Malcolm Matalka]

Anton Bachin <antronbachin@gmail.com> writes:

> 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."

To add some more terminology to the mix, I have generally seen Future
and Promise being two sides of the same thing.  A Future is a read-only
value that can be determined to a value and a Promise is the side that
can be set.  The wikipedia entry uses this terminology.

https://en.wikipedia.org/wiki/Futures_and_promises

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

[Andreas Rossberg]

> On Jan 7, 2017, at 11:56 , Malcolm Matalka <mmatalka@gmail.com> wrote:
> 
> To add some more terminology to the mix, I have generally seen Future
> and Promise being two sides of the same thing.  A Future is a read-only
> value that can be determined to a value and a Promise is the side that
> can be set.  The wikipedia entry uses this terminology.
> 
> https://en.wikipedia.org/wiki/Futures_and_promises

The history of the future/promise terminology is somewhat confusing. Friedman & Wise introduced the concept as promises, Baker & Hewitt (re)named it futures (there are only superficial differences). They gained wider popularity with Multilisp, which also called them futures. As far as the functional language space is concerned, that term pretty much stuck. In the imperative/OO space, the term promise became somewhat popular with Liskov & Shrira and their promise pipelining. However, most contemporary mainstream languages (C++, Java, ...) also use future.

As far as I am aware, Alice ML was the first language that had _both_ futures and promises and factorised them in the way you cite, where promises are essentially single assignment variables — at least I remember that we iterated on various terminologies for a long time around 99/00 until we settled on this. I don’t know how the future/promise API in C++ came about, but it arrived at a very similar distinction. So did Scala. All these languages characterise promises by the presence of a resolve/‘fulfill' operator.

There is a different distinction being made by e.g. Mark Miller, who characterises futures by a (synchronous, blocking) read operation, and promises by a (asynchronous, nonblocking) bind operator taking a callback. Personally, I find this use of terminology rather unintuitive and problematic, since there is no reason that a blocking future cannot also have a non-blocking bind method (and they often do). But it is the reason that JavaScript calls its notion promise (although there was discussion about that). Arguably, though, it is the odd one out as far as both mainstream and functional languages are concerned.

(More generally, I would not recommend using JavaScript as precedent for anything regarding its promises, since they are broken in just about every possible way. And I’m saying that as a member of the committee that standardised them… :) )

/Andreas

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

[Michael Grünewald]

> On 9 Jan 2017, at 18:04, Andreas Rossberg <rossberg@mpi-sws.org> wrote:
> 
> (More generally, I would not recommend using JavaScript as precedent for anything regarding its promises, since they are broken in just about every possible way. And I’m saying that as a member of the committee that standardised them… :) )

As an occasional JS promise user, I am (genuinely) curious to know what
you consider them broken in them.  If you have a few minutes for this,
I would really enjoy to read a few starting points on this question.

Thanks!