caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Ivan Gotovchits <ivg@ieee.org>
To: Anton Bachin <antronbachin@gmail.com>
Cc: "caml-list@inria.fr users" <caml-list@inria.fr>
Subject: Re: [Caml-list] [ANN] Lwt 2.7.0 – monadic promises; concurrent I/O
Date: Fri, 6 Jan 2017 13:00:02 -0500	[thread overview]
Message-ID: <CALdWJ+wDTuRn1inxZvw1ABXR497z=OWab6MxZ+RMUmGOD52mCg@mail.gmail.com> (raw)
In-Reply-To: <22A97EAF-DBFF-4FE8-90C3-0343533CC621@gmail.com>

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

  reply	other threads:[~2017-01-06 18:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-06 16:08 Anton Bachin
2017-01-06 18:00 ` Ivan Gotovchits [this message]
2017-01-06 18:12   ` Ivan Gotovchits
2017-01-06 18:39     ` Xavier Van de Woestyne
2017-01-06 19:41   ` Anton Bachin
2017-01-06 20:36     ` Ivan Gotovchits
2017-01-07 10:56     ` Malcolm Matalka
2017-01-09 17:04       ` Andreas Rossberg
2017-01-11  8:57         ` Michael Grünewald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALdWJ+wDTuRn1inxZvw1ABXR497z=OWab6MxZ+RMUmGOD52mCg@mail.gmail.com' \
    --to=ivg@ieee.org \
    --cc=antronbachin@gmail.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).