Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

classic Classic list List threaded Threaded
243 messages Options
1 ... 910111213
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Edward Kmett-2
On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland <[hidden email]> wrote:

>     I outlined one possible path to avoid this kind of issue: spend more
>     time thinking about ways to maintain compatibility. We had
>     proposals for
>     doing this with AMP.
>
>
> And on the other hand we also had a concrete proposal that didn't
> require language changes that was ridiculously popular. People had
> been talking about Applicative as a superclass of Monad for a decade
> before we finally acted upon the AMP. People had been talking about
> superclass defaulting for a decade. When do you cut off discussion and
> ship the proposal that has overwhelming support? If there is no
> process that enables this you can stall the process indefinitely by
> raising objections of this form. Such a situation is not without costs
> all its own.
>

I agree. It was certainly within the power of the committee to start a
clock and say something like "if we don't have a patch to GHC that
provides backwards compatibility for AMP within 1 year, we will push out
AMP as-is." Had I understand the implications of AMP at the time, or
even been aware that AMP was happening (I was actually actively working
on the GHC code base during that period), that certainly would have been
motivation for me to do something about it! *That* would be how one
could cut off discussion and ship a proposal.

I freely admit that there is room for improvement in the process. We're all learning here.

The current Semigroup-Monoid proposal more or less fits the bill you are looking for here. We have a roadmap today that migrates an existing package with several years worth of back support into base more or less unmodified, and then in 3 releases starts requiring instances. You can think of that 3 release clock as precisely what you are looking for here.

If we get an implementation of superclass defaulting or some other mechanism that can mitigate the extra couple of lines of code that this proposal will tax users with, within that timeline, we'd gladly incorporate it into the proposal.
 
I am not against changing the Prelude! But it sure would be nice if
-XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a
Haskell 2010 Prelude, both of which could be used with external packages
that themselves used the more modern Prelude.

It would definitely be a preferable state of affairs. Unfortunately, at least with the tools available to us today, such a plan is incompatible with any plan that introduces a new superclass. It also cuts off plans that ever factors an existing class into two, such as the MonadFail proposals. We simply do not at this time have the technical capabilities that would support such a system. If they showed up in GHC we can adapt plans to fit.
 
Maybe that's impossible.
Setting a firm deadline to finding a solution to the compatibility issue
would have been a way to compromise. Ideally, changing the Prelude
wouldn't require breaking code written to use an older version of the
Prelude. Yes, attaining that goal would require more work.

We looked around for a year for a roadmap that would get us there. None presented itself. In the end we wound up shedding the core libraries status of the haskell98 and haskell2010 packages as the 3-4 different ways in which one could write a Haskell2010 package all have different trade-offs and can be maintained in user-land.

Examples:

* A hardline version of haskell2010 with a Monad and Num that fully complies with the report, but which doesn't work with Monad and Num instances supplied by other libraries. This needs RebindableSyntax, so it doesn't quite work right. With compiler support for rebinding syntax to a particular library instead of to whatever is in scope, such a thing might be suitable for teaching a Haskell class.

* A pragmatic haskell2010 where the Monad has an Applicative superclass and Num has the current semantic. This works with everything but doesn't faithfully follow the report. 

*  A middle-ground package that tries to use a superclass defaulting mechanism that we don't have to supply missing Applicative superclasses might resolve the Applicative-Monad issue in theory, but does nothing for report compliance of our existing Num.

Each one of these solutions has flaws. Two of them require innovations in the compiler that we don't have.
 
Evolving the Prelude and maintaining compatibility are not necessarily
mutually exclusive options.

Agreed, but as you can see above, maintaining compatibility isn't necessarily always a viable option either.

-Edward

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Gregory Collins-3
In reply to this post by Edward Kmett-2

On Wed, Oct 21, 2015 at 11:40 PM, Edward Kmett <[hidden email]> wrote:
All I'm saying is that if we want to appeal to or cater to working software engineers, we have to be a lot less cavalier about causing more work for them, and we need to prize stability of the core infrastructure more highly. That'd be a broader cultural change, and that goes beyond process: it's policy.

The way things are shaping up, we've had 17 years of rock solid stability

I have >95% confidence that all of the C++ programs I wrote 15 years ago would build and work if I dusted them off and typed "make" today. I have Haskell programs I wrote last year that I probably couldn't say that about.

So I don't buy that, at all, at least if we're discussing the topic of the stability of the core infrastructure in general rather than changes being made to the Prelude. It's been possible to write to Haskell 98 without too much breakage, yes, but almost nobody actually does that; they write to Haskell as defined by GHC + the boot libraries + Haskell platform + Hackage, IMO with decreasing expectations of stability for each. The core set breaks a lot. We definitely shouldn't adopt a posture to breaking changes as conservative as the C++ committee's, and literally nobody in the Haskell community is arguing against breaking changes in general, but as I've pointed out, most of these breakages could have been avoided with more careful engineering, and indeed, on many occasions the argument has been made and it's fallen on deaf ears.

They can speak for themselves but I think for Mark and Johan, this is a "straw that broke the camel's back" issue rather than anything to do with the merits of removing return from Monad. I think the blowback just happens to be so much stronger on MRP because the breaking change is so close to the core of the language, and the benefits are so nebulous: fixing an aesthetic problem has almost zero practical value, and ">> could be slightly more efficient for some monads" is pretty weak sauce.

--
Gregory Collins <[hidden email]>

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Geoffrey Mainland
In reply to this post by Edward Kmett-2
On 10/22/2015 01:29 PM, Edward Kmett wrote:

> On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland
> <[hidden email] <mailto:[hidden email]>> wrote:
>  
>
>     I am not against changing the Prelude! But it sure would be nice if
>     -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a
>     Haskell 2010 Prelude, both of which could be used with external
>     packages
>     that themselves used the more modern Prelude.
>
>
> It would definitely be a preferable state of affairs. Unfortunately,
> at least with the tools available to us today, such a plan is
> incompatible with any plan that introduces a new superclass. It also
> cuts off plans that ever factors an existing class into two, such as
> the MonadFail proposals. We simply do not at this time have the
> technical capabilities that would support such a system. If they
> showed up in GHC we can adapt plans to fit.

Great!

Could we work to characterize what technical capabilities we would need
to support full backwards Prelude compatibility?

Here is my rough understanding of what we would need:

1) Some method for "default superclasses." This would solve the AMP issue.

2) A method for factoring existing classes into two (or more) parts.
This would solve the MonadFail problem.

3) A method for imposing extra superclass constraints on a class. This
would be needed for full Num compatibility. Seems much less important
that 1 and 2.

The most thought has gone into 1.

Are these three technical capabilities *all* that we would need? Perhaps
we also need a way to tie the current language (-XHaskell98,
-XHaskell2010) to a particular implementation of the Prelude.

Geoff
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Edward Kmett-2

On Thu, Oct 22, 2015 at 1:41 PM, Geoffrey Mainland <[hidden email]> wrote:
On 10/22/2015 01:29 PM, Edward Kmett wrote:
> On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>
>     I am not against changing the Prelude! But it sure would be nice if
>     -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a
>     Haskell 2010 Prelude, both of which could be used with external
>     packages
>     that themselves used the more modern Prelude.
>
>
> It would definitely be a preferable state of affairs. Unfortunately,
> at least with the tools available to us today, such a plan is
> incompatible with any plan that introduces a new superclass. It also
> cuts off plans that ever factors an existing class into two, such as
> the MonadFail proposals. We simply do not at this time have the
> technical capabilities that would support such a system. If they
> showed up in GHC we can adapt plans to fit.

Great!

Could we work to characterize what technical capabilities we would need
to support full backwards Prelude compatibility?

Here is my rough understanding of what we would need:

1) Some method for "default superclasses." This would solve the AMP issue.

2) A method for factoring existing classes into two (or more) parts.
This would solve the MonadFail problem.

3) A method for imposing extra superclass constraints on a class. This
would be needed for full Num compatibility. Seems much less important
that 1 and 2.

The most thought has gone into 1.

Are these three technical capabilities *all* that we would need? Perhaps
we also need a way to tie the current language (-XHaskell98,
-XHaskell2010) to a particular implementation of the Prelude.
 
I don't have a concrete plan here. I'm not even sure one can be achieved that works. I'd say that the burden of figuring out such a thing falls on the party that can create a plan, pitch it to the community and potentially implement it.

If I enumerate a set of conditions here I'm basically implying that I'd agree to any plan that incorporated them. I'm just not prepared to make that commitment sight-unseen to something with unknown warts and implications.

I can, however, say that it is plausible that what you have enumerated above could potentially address the outstanding issues, but I don't know how good of a compromise the result would be. 

-Edward

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Edward Kmett-2
In reply to this post by Gregory Collins-3
On Thu, Oct 22, 2015 at 1:37 PM, Gregory Collins <[hidden email]> wrote:

On Wed, Oct 21, 2015 at 11:40 PM, Edward Kmett <[hidden email]> wrote:
All I'm saying is that if we want to appeal to or cater to working software engineers, we have to be a lot less cavalier about causing more work for them, and we need to prize stability of the core infrastructure more highly. That'd be a broader cultural change, and that goes beyond process: it's policy.

The way things are shaping up, we've had 17 years of rock solid stability

I have >95% confidence that all of the C++ programs I wrote 15 years ago would build and work if I dusted them off and typed "make" today. I have Haskell programs I wrote last year that I probably couldn't say that about.

So I don't buy that, at all, at least if we're discussing the topic of the stability of the core infrastructure in general rather than changes being made to the Prelude. It's been possible to write to Haskell 98 without too much breakage, yes, but almost nobody actually does that; they write to Haskell as defined by GHC + the boot libraries + Haskell platform + Hackage, IMO with decreasing expectations of stability for each. The core set breaks a lot.

I definitely agree here. 

We have a lot of libraries in the Haskell Platform that have fairly liberal change policies. On the other hand, we have a policy of "maintainer decides" around issues. This yields a fairly decentralized change management process, with different maintainers who have different views. The Platform gives us a central pool of packages that are generally the "best of breed" in their respective spaces, but gives us few stability guarantees. 

Heck, every release I wind up having to change whatever code I have that uses template-haskell or Typeable.

On the other hand, it isn't clear with a larger "core" platform with harder stability guarantees that we have a volunteer force that can and would sign up for the long slog of maintenance without that level of autonomy.
 
We definitely shouldn't adopt a posture to breaking changes as conservative as the C++ committee's, and literally nobody in the Haskell community is arguing against breaking changes in general, but as I've pointed out, most of these breakages could have been avoided with more careful engineering, and indeed, on many occasions the argument has been made and it's fallen on deaf ears.

I would argue that there are individual maintainers that give lie to that statement. In many ways Johan himself has served as a counter-example there. The libraries he has maintained have acted as a form of bedrock with long maintenance windows. On the other hand, the burden of maintaining that stability seems to have ultimately burned him out.

They can speak for themselves but I think for Mark and Johan, this is a "straw that broke the camel's back" issue rather than anything to do with the merits of removing return from Monad. I think the blowback just happens to be so much stronger on MRP because the breaking change is so close to the core of the language, and the benefits are so nebulous. fixing an aesthetic problem has almost zero practical value

I personally don't care about the return side of the equation.

Herbert's MRP proposal was an attempt by him to finish out the changes started by AMP so that a future Haskell Report can read cleanly. Past reports have been remarkably free of historical baggage.

I'd personally readily sacrifice "progress" there in the interest of harmony. Herbert as haskell-prime chair possibly feels differently.
 
and ">> could be slightly more efficient for some monads" is pretty weak sauce.

The issue right now around (>>) is that it has knock-on effects that run pretty far and wide. "Weak sauce" or not, it means through second order consequences that we can't move the useless mapM and sequence to the top level from their current status as memberrs of Traversable and that users have to care about which of two provably equivalent things that they are using, at all times. 

It means that code that calls mapM will be less efficient and that mapM_ behaves in a manner with rather radically different space and time behavior than mapM today and not in a consistently good way.

-Edward

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Bardur Arantsson-2
In reply to this post by Gregory Collins-3
On 10/22/2015 07:37 PM, Gregory Collins wrote:

> On Wed, Oct 21, 2015 at 11:40 PM, Edward Kmett <[hidden email]> wrote:
>
>> All I'm saying is that if we want to appeal to or cater to working
>>> software engineers, we have to be a lot less cavalier about causing more
>>> work for them, and we need to prize stability of the core infrastructure
>>> more highly. That'd be a broader cultural change, and that goes beyond
>>> process: it's policy.
>>>
>>
>> The way things are shaping up, we've had 17 years of rock solid stability
>>
>
> I have >95% confidence that all of the C++ programs I wrote 15 years ago
> would build and work if I dusted them off and typed "make" today. I have
> Haskell programs I wrote last year that I probably couldn't say that about.
>

I wouldn't be so confident, if I were you :). Did you use *any* external
libraries in your project? You'll probably find that no distibution
actually ships the versions you used. Did you have any
implemenetation-defined behavior in your project? That behavior may well
have changed with a more up-to-date compiler -- and good luck getting
that old compiler running on any current platform. (&c.)

It would be interesting as a data point if you could just try a few
projects.

Regards,


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Geoffrey Mainland
In reply to this post by Edward Kmett-2
On 10/22/2015 02:25 PM, Edward Kmett wrote:

>
> On Thu, Oct 22, 2015 at 1:41 PM, Geoffrey Mainland
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 10/22/2015 01:29 PM, Edward Kmett wrote:
>     > On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland
>     > <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >
>     >     I am not against changing the Prelude! But it sure would be
>     nice if
>     >     -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010
>     gave me a
>     >     Haskell 2010 Prelude, both of which could be used with external
>     >     packages
>     >     that themselves used the more modern Prelude.
>     >
>     >
>     > It would definitely be a preferable state of affairs. Unfortunately,
>     > at least with the tools available to us today, such a plan is
>     > incompatible with any plan that introduces a new superclass. It also
>     > cuts off plans that ever factors an existing class into two, such as
>     > the MonadFail proposals. We simply do not at this time have the
>     > technical capabilities that would support such a system. If they
>     > showed up in GHC we can adapt plans to fit.
>
>     Great!
>
>     Could we work to characterize what technical capabilities we would
>     need
>     to support full backwards Prelude compatibility?
>
>     Here is my rough understanding of what we would need:
>
>     1) Some method for "default superclasses." This would solve the
>     AMP issue.
>
>     2) A method for factoring existing classes into two (or more) parts.
>     This would solve the MonadFail problem.
>
>     3) A method for imposing extra superclass constraints on a class. This
>     would be needed for full Num compatibility. Seems much less important
>     that 1 and 2.
>
>     The most thought has gone into 1.
>
>
>     Are these three technical capabilities *all* that we would need?
>     Perhaps
>     we also need a way to tie the current language (-XHaskell98,
>     -XHaskell2010) to a particular implementation of the Prelude.
>
>  
> I don't have a concrete plan here. I'm not even sure one can be
> achieved that works. I'd say that the burden of figuring out such a
> thing falls on the party that can create a plan, pitch it to the
> community and potentially implement it.
>
> If I enumerate a set of conditions here I'm basically implying that
> I'd agree to any plan that incorporated them. I'm just not prepared to
> make that commitment sight-unseen to something with unknown warts and
> implications.
>
> I can, however, say that it is plausible that what you have enumerated
> above could potentially address the outstanding issues, but I don't
> know how good of a compromise the result would be.
>
> -Edward

I don't have a concrete plan either, not am I sure that one is possible.
But I don't see how having a conversation about how one might achieve
backwards compatibility would commit anyone to anything. Any eventual
proposal would have to go through the same approval process as every
other proposal. And even if we did have a hypothetical draft proposal
that you had at some point stated you approved of in some way, you would
always be free to change your mind!

Isn't the libraries list exactly where this sort of conversation should
happen?

Cheers,
Geoff
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Breaking Changes and Long Term Support Haskell

Simon Peyton Jones
| >     Are these three technical capabilities *all* that we would need?
| >     Perhaps
| >     we also need a way to tie the current language (-XHaskell98,
| >     -XHaskell2010) to a particular implementation of the Prelude.
| >
| >
| > I don't have a concrete plan here. I'm not even sure one can be
| > achieved that works. I'd say that the burden of figuring out such a
| > thing falls on the party that can create a plan, pitch it to the
| > community and potentially implement it.

In fact there is more than one concrete plan: https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses

All are complex, only partially designed, entirely unimplemented (and the implementation will be non-trivial), and lacking an active champion.  The one I link to above is probably the leading contender, but it feels too complicated to me.

Simon

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Herbert Valerio Riedel
In reply to this post by 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

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

attachment0 (834 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Francesco Ariis
On Thu, Nov 05, 2015 at 11:46:32AM +0100, Herbert Valerio Riedel wrote:
> Hello everybody,

Hello,
    I would suggest to start a new thread for this proposal.
The old one (check it on gmane [1]) is approaching "unholy evil"
levels of length/nested discussion, a fresh start might benefit
the discussion (and result in cleaner archiving).

[1] http://thread.gmane.org/gmane.comp.lang.haskell.libraries/25380/focus=118576
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Greg Weber
Thanks for the clear revisions! It is unclear from the proposal how well the automatic re-factoring tool is expected to work.

On Thu, Nov 5, 2015 at 6:18 AM, Francesco Ariis <[hidden email]> wrote:
On Thu, Nov 05, 2015 at 11:46:32AM +0100, Herbert Valerio Riedel wrote:
> Hello everybody,

Hello,
    I would suggest to start a new thread for this proposal.
The old one (check it on gmane [1]) is approaching "unholy evil"
levels of length/nested discussion, a fresh start might benefit
the discussion (and result in cleaner archiving).

[1] http://thread.gmane.org/gmane.comp.lang.haskell.libraries/25380/focus=118576
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: MRP Summary & revised MRP 2ed

Alexander Berntsen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/11/15 15:53, Greg Weber wrote:
> Thanks for the clear revisions! It is unclear from the proposal
> how well the automatic re-factoring tool is expected to work.
The obvious answer is that it will be as good as possible. :-]

It would be very beneficial if people who use Haskell in an academic
or commercial setting -- thus actively benefiting from it -- were able
to spend some of their time on this project. That way the roof for "as
good as possible" will likely be raised considerably.
- --
Alexander
[hidden email]
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWO28fAAoJENQqWdRUGk8Bfm4QAMpMJakhtwopvvJDobr4svZ2
WE4oW88d6LoDIzFTG5654RG78fyKkyGE+WllfH+X1OgV/3/YT1iczE73ysgxS5k4
wivhEzt4HvlITmF8H6qYJDie+X08IHgaCUMseMOhh/fxyy+YF1cr4hF5P9mEWP+9
ti4HC3Y4rjB86U78mbhTVUj6fiF2NLkM7Y2Bxf2vHvbfGwUVh4QA8sSyM7rSSjDP
OlZW3fMMNFuhaqvIlYOcr/slHq/r+pe+88X5MJLPen1ALPksjzdyd1Izw1wdCL3y
zTGMO94aFlvkbomGCgCUzCFaPUqewvn0P0W5I38jmLM8D7AwRTQBTd/oz53AumsK
Km0RtHEs7MW5FQ8dA5+vMLZblxjpXAK9BOvUIkr1Rt44wnDLU86hWEBBFsb5H0+m
Kdc5WGfn4AjuESXvG29UrLSyU2eAwYUF60W8Y2hEt9nGs/IrrtSjpC46W5FPi9LR
F1GHuYBJobEQ6K6TvjVzQ73ajPH9Vwm3d8+BV8eBd5Z62MkgF23M0HWHuR0JUo4X
YjLutYzo+oAkeF4tOzLO0TIvQx6pyncj/CDMZL+ZLMrhHYP2yIuXEQixXs3yi2og
GJi453l0RbCEjKj+cPek/ZCwtNtf/tMvSD/Rr6yjCAIE67eaC9h/NsxFn9fNQzRJ
O3cfg4wlIvcZDSsx6qGw
=jB4v
-----END PGP SIGNATURE-----
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: MRP Summary & revised MRP 2ed

Herbert Valerio Riedel-3
In reply to this post by Greg Weber
Hi,

On 2015-11-05 at 15:53:39 +0100, Greg Weber wrote:
> Thanks for the clear revisions! It is unclear from the proposal how well
> the automatic re-factoring tool is expected to work.

Currently, Hs2010To201x does the following few things:

When a `Monad` instance definition is detected in a module,

 - if needed, define respective `Functor` instance (AMP)
 - if needed, define respective `Applicative` instance (AMP)
 - if needed, refactor return/pure definitions into canonical form (MRP)

This works fairly well for most common `Monad` instances. I ran it on
Cabal's code-base (for which only the MRP refactoring was relevant), and
the result looked very promising:

  https://gist.github.com/hvr/cd35fbcff9be6f3cb2a9


However, the major obstacle so far is CPP, which generally causes
problems with other tooling as well, and in particular /can/ confuse
ghc-exactprint.

Another source of problems are orphan-instances (specifically when the
`Applicative` instance is defined in a different module from the module
where the `Monad` instance is defined) as the tool currently operates on
single modules at a time.

Finally, the less frequent cases of nested Monads which require to
construct proper instance constraints for `Functor`/`Applicatives`
instances are not handled adequately yet. Examples are
`instance (Monad m) => Monad (ListT m)` or
`instance (Monad m) => Monad (StateT s m)`.


--HVR
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Akio Takano
In reply to this post by Herbert Valerio Riedel
Hi Herbert,

On Thu, Nov 5, 2015 at 10:46 AM, Herbert Valerio Riedel <[hidden email]> wrote:

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

I'm sorry to join the discussion so late, but I'd like to mention one
thing that doesn't seem to have been brought up. If I understand
correctly, this proposal can silently slow down existing programs,
sometimes even asymptotically. This applies when a monad is defined
with no explicit definition for (>>) nor for (*>).

The problem is this: currently, when a Monad instance lacks an
explicit definition for (>>), a default implementation based on (>>=)
is used. After this proposal, (>>) would be an alias for (*>), for
which there is a default implementation based on (<*>). However, at
least for some monads, the former is a much better default.

[1] is one example where it makes an asymptotic difference in runtime.
This type of difference arises when (>>=) has to linearly traverse its
LHS, but not its RHS.

[1] https://ghc.haskell.org/trac/ghc/ticket/10711#comment:1

I also constructed another example [2]. This is a standard
implementation of the strict State monad, except that (>>=) is
implemented as a NOINLINE function. You can see that using (*>) in
place of (>>) changes the memory usage of the program from constant to
linear. The difference here arises from the fact that the default
implementation for (>>) can "tail-call" its RHS as long as (>>=) also
has this tail-call property, but the default implementation of (*>)
cannot.

[2] https://gist.github.com/takano-akio/7066c511b60d6ab090c5

In my opinion introducing this kind of performance regression is quite
bad. Although I agree that it's frustrating that we are stuck with
mapM, mapM_ etc., I believe this should be fixed in a way that doesn't
make (>>) slower by default.

Regards,
Takano Akio

>
> 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
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
(>>) becomes slower by default in some cases and drastically faster in others, but since the definition is a member in a class it can actually be fixed by people.

In situations where (<*>) is asymptotically more efficient than (>>=) then the default definition in terms of (<*>) wins.

Right now, if you run through hackage there are lots of places where (>>) has been manually improved but the (*>) has not -- or vice versa. We have two places where people should apply an optimization and many have only realized that they should optimize one or the other.

The key here is to encourage folks to actually define (*>) when it matters.

-Edward

On Wed, Nov 25, 2015 at 2:37 AM, Akio Takano <[hidden email]> wrote:
Hi Herbert,

On Thu, Nov 5, 2015 at 10:46 AM, Herbert Valerio Riedel <[hidden email]> wrote:
> 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.

I'm sorry to join the discussion so late, but I'd like to mention one
thing that doesn't seem to have been brought up. If I understand
correctly, this proposal can silently slow down existing programs,
sometimes even asymptotically. This applies when a monad is defined
with no explicit definition for (>>) nor for (*>).

The problem is this: currently, when a Monad instance lacks an
explicit definition for (>>), a default implementation based on (>>=)
is used. After this proposal, (>>) would be an alias for (*>), for
which there is a default implementation based on (<*>). However, at
least for some monads, the former is a much better default.

[1] is one example where it makes an asymptotic difference in runtime.
This type of difference arises when (>>=) has to linearly traverse its
LHS, but not its RHS.

[1] https://ghc.haskell.org/trac/ghc/ticket/10711#comment:1

I also constructed another example [2]. This is a standard
implementation of the strict State monad, except that (>>=) is
implemented as a NOINLINE function. You can see that using (*>) in
place of (>>) changes the memory usage of the program from constant to
linear. The difference here arises from the fact that the default
implementation for (>>) can "tail-call" its RHS as long as (>>=) also
has this tail-call property, but the default implementation of (*>)
cannot.

[2] https://gist.github.com/takano-akio/7066c511b60d6ab090c5

In my opinion introducing this kind of performance regression is quite
bad. Although I agree that it's frustrating that we are stuck with
mapM, mapM_ etc., I believe this should be fixed in a way that doesn't
make (>>) slower by default.

Regards,
Takano Akio

>
> 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
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Akio Takano
On Wed, Nov 25, 2015 at 7:05 PM, Edward Kmett <[hidden email]> wrote:
> (>>) becomes slower by default in some cases and drastically faster in
> others, but since the definition is a member in a class it can actually be
> fixed by people.

This is true, but I think it's much better to avoid breaking people's
code in the first place. Also, since the breakage can be silent, one
will not always be able to make a fix promptly.

>
> In situations where (<*>) is asymptotically more efficient than (>>=) then
> the default definition in terms of (<*>) wins.

You are right. I hadn't thought about this.

>
> Right now, if you run through hackage there are lots of places where (>>)
> has been manually improved but the (*>) has not -- or vice versa. We have
> two places where people should apply an optimization and many have only
> realized that they should optimize one or the other.
>
> The key here is to encourage folks to actually define (*>) when it matters.

I understand this, but perhaps there is a way to achieve this without
slowing down existing code. How about introducing a new warning
(enabled with -Wall) that is triggered when a type satisfies the
following 3 conditions?

1. The type has a Monad instance and an Applicative instance declared
in the same module, with the same set of constraints.
2. (*>) is not defined as (*>) = (>>). i.e. either it has a
non-trivial definition or its definition is left out.
3. (>>) is not defined as (>>) = (*>). i.e. either it has a
non-trivial definition or its definition is left out.

This way, people can be warned when (*>) and (>>) can share an
implementation but they don't.

- Akio

>
> -Edward
>
> On Wed, Nov 25, 2015 at 2:37 AM, Akio Takano <[hidden email]> wrote:
>>
>> Hi Herbert,
>>
>> On Thu, Nov 5, 2015 at 10:46 AM, Herbert Valerio Riedel <[hidden email]>
>> wrote:
>> > 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.
>>
>> I'm sorry to join the discussion so late, but I'd like to mention one
>> thing that doesn't seem to have been brought up. If I understand
>> correctly, this proposal can silently slow down existing programs,
>> sometimes even asymptotically. This applies when a monad is defined
>> with no explicit definition for (>>) nor for (*>).
>>
>> The problem is this: currently, when a Monad instance lacks an
>> explicit definition for (>>), a default implementation based on (>>=)
>> is used. After this proposal, (>>) would be an alias for (*>), for
>> which there is a default implementation based on (<*>). However, at
>> least for some monads, the former is a much better default.
>>
>> [1] is one example where it makes an asymptotic difference in runtime.
>> This type of difference arises when (>>=) has to linearly traverse its
>> LHS, but not its RHS.
>>
>> [1] https://ghc.haskell.org/trac/ghc/ticket/10711#comment:1
>>
>> I also constructed another example [2]. This is a standard
>> implementation of the strict State monad, except that (>>=) is
>> implemented as a NOINLINE function. You can see that using (*>) in
>> place of (>>) changes the memory usage of the program from constant to
>> linear. The difference here arises from the fact that the default
>> implementation for (>>) can "tail-call" its RHS as long as (>>=) also
>> has this tail-call property, but the default implementation of (*>)
>> cannot.
>>
>> [2] https://gist.github.com/takano-akio/7066c511b60d6ab090c5
>>
>> In my opinion introducing this kind of performance regression is quite
>> bad. Although I agree that it's frustrating that we are stuck with
>> mapM, mapM_ etc., I believe this should be fixed in a way that doesn't
>> make (>>) slower by default.
>>
>> Regards,
>> Takano Akio
>>
>> >
>> > 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
>> >
>> > _______________________________________________
>> > Libraries mailing list
>> > [hidden email]
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> >
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: MRP Summary & revised MRP 2ed

Herbert Valerio Riedel
On 2015-11-26 at 09:28:32 +0100, Akio Takano wrote:

[...]

> I understand this, but perhaps there is a way to achieve this without
> slowing down existing code. How about introducing a new warning
> (enabled with -Wall) that is triggered when a type satisfies the
> following 3 conditions?
>
> 1. The type has a Monad instance and an Applicative instance declared
> in the same module, with the same set of constraints.
> 2. (*>) is not defined as (*>) = (>>). i.e. either it has a
> non-trivial definition or its definition is left out.
> 3. (>>) is not defined as (>>) = (*>). i.e. either it has a
> non-trivial definition or its definition is left out.
>
> This way, people can be warned when (*>) and (>>) can share an
> implementation but they don't.

Coincidentally, I've recently implemented something similar to that end
(but it is *not* enabled via -Wall/-Wcompat by default yet), see

  https://git.haskell.org/ghc.git/commitdiff/f09f2470a76bb08b7f51d2f5663daa672b86f618

for details.

Cheers,
  hvr
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
In reply to this post by Akio Takano
On Thu, Nov 26, 2015 at 3:28 AM, Akio Takano <[hidden email]> wrote:
This is true, but I think it's much better to avoid breaking people's
code in the first place. Also, since the breakage can be silent, one
will not always be able to make a fix promptly.

We're not talking about making this change until we can get some warnings in place. 

That said, in the presence of some existing combinators that have already been generalized from Monad to Applicative you may want to ensure that these definitions have been fixed already.

>
> In situations where (<*>) is asymptotically more efficient than (>>=) then
> the default definition in terms of (<*>) wins.

You are right. I hadn't thought about this.

>
> Right now, if you run through hackage there are lots of places where (>>)
> has been manually improved but the (*>) has not -- or vice versa. We have
> two places where people should apply an optimization and many have only
> realized that they should optimize one or the other.
>
> The key here is to encourage folks to actually define (*>) when it matters.

I understand this, but perhaps there is a way to achieve this without
slowing down existing code. How about introducing a new warning
(enabled with -Wall) that is triggered when a type satisfies the
following 3 conditions?

1. The type has a Monad instance and an Applicative instance declared
in the same module, with the same set of constraints.
2. (*>) is not defined as (*>) = (>>). i.e. either it has a
non-trivial definition or its definition is left out.
3. (>>) is not defined as (>>) = (*>). i.e. either it has a
non-trivial definition or its definition is left out.

This way, people can be warned when (*>) and (>>) can share an
implementation but they don't.

This is pretty much what Herbert has been working on, except with the definition biased in favor of (>>) = (*>) being expected, and the other becoming a warning as that definition blows up when and if we later move (>>) out of the class.

-Edward

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: MRP Summary & revised MRP 2ed

Akio Takano
In reply to this post by Herbert Valerio Riedel
On Thu, Nov 26, 2015 at 8:36 AM, Herbert Valerio Riedel <[hidden email]> wrote:

> On 2015-11-26 at 09:28:32 +0100, Akio Takano wrote:
>
> [...]
>
>> I understand this, but perhaps there is a way to achieve this without
>> slowing down existing code. How about introducing a new warning
>> (enabled with -Wall) that is triggered when a type satisfies the
>> following 3 conditions?
>>
>> 1. The type has a Monad instance and an Applicative instance declared
>> in the same module, with the same set of constraints.
>> 2. (*>) is not defined as (*>) = (>>). i.e. either it has a
>> non-trivial definition or its definition is left out.
>> 3. (>>) is not defined as (>>) = (*>). i.e. either it has a
>> non-trivial definition or its definition is left out.
>>
>> This way, people can be warned when (*>) and (>>) can share an
>> implementation but they don't.
>
> Coincidentally, I've recently implemented something similar to that end
> (but it is *not* enabled via -Wall/-Wcompat by default yet), see
>
>   https://git.haskell.org/ghc.git/commitdiff/f09f2470a76bb08b7f51d2f5663daa672b86f618
>
> for details.

Thank you for the information. If I understand correctly, this
-fwarn-noncanonical-monad-instances warning doesn't address my
concern, because it won't warn about a monad that defines neither (>>)
nor (*>) explicitly, which I expect to be a common case.

- Akio

>
> Cheers,
>   hvr
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: MRP Summary & revised MRP 2ed

Herbert Valerio Riedel-3
Hi,

On 2015-11-27 at 10:29:09 +0100, Akio Takano wrote:

[...]

> Thank you for the information. If I understand correctly, this
> -fwarn-noncanonical-monad-instances warning doesn't address my
> concern, because it won't warn about a monad that defines neither (>>)
> nor (*>) explicitly, which I expect to be a common case.

You're right, from what I've seen the majority of Monad instances don't
bother to override (>>)/(*>) currently.

But do we really want every Applicative/Monad to explicitly define (*>)
(and consequently (>>)=(*>)) ?

If so, it seems to be unfortunate that we have an overridable default
implementation for (*>)/(>>) in place, as that IMO suggests that you're
only supposed to override (*>) in those less common cases where it
provides a benefit over the default implementation. What's the point of
the default implementation otherwise?


-- hvr
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
1 ... 910111213