MRP Summary & revised MRP 2ed (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

[Herbert Valerio Riedel]

Hello everybody,

Based on the feedback gathered from the discussion, the proposal has
been revised to address the raised concerns. The highlights are:

 - A new stretched out transition scheme complying with the recently
   enacted ​3-release policy (and beyond) has been devised.

 - Unifying `>>`/`*>` has been incorporated into the proposal in the
   interest of bundling changes of obviously related changes.

 - Moreover, the feasibility of automatic refactoring tooling was
   investigated and resulted in the working `Hs2010To201x`
   proof-of-concept.

Please re-read the revised proposal at

  https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn

for more details (or use the Wiki's diffing feature to see what changed
relative to the original revision) if you want to comment, so we can
focus on discussing the actual revised version.

Also, as per proposal guidelines, and more importantly, for the benefit
of those that lost track of this rather complex discussion, I've tried
to summarize the core of discussion over at

  https://ghc.haskell.org/wiki/Proposal/MonadOfNoReturn/Discussion

More importantly, based on feedback gathered as well as concerns raised
throughout the discussion, I've revised and extended the proposal into a
"2nd edition MRP". I feel confident the new revised proposal addresses
the major concerns as well as adhering to the recently requested 3-yr
compatibility policy.

PS: One common oversight I noticed when reviewing the discussion is
    that the last-minute proposal addition -- of unifying `>>`/`*>` in
    the same vein as `pure`/`return` -- wasn't noticed by many who
    joined the debate late.

    However, Unifying `>>`/`*>` and `pure`/`return` are in my opinion
    strongly related concerns as they share the same rationale about
    correctness issues and it doesn't make sense to do one without the
    other. However, the transition time-scales could be set slightly
    different to account for the more breaking nature of effectively
    changing `>>`'s current default method operational semantics.

Thanks,
  Herbert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151105/aa3888b2/attachment.sig>