Hi, On 2015-10-06 at 21:32:19 +0200, Mikhail Glushenkov wrote:

On 6 October 2015 at 19:03, Herbert Valerio Riedel wrote:

...

...

In the specific case of MRP, I can offer you a Wall-perfect transition scheme by either using `ghc-options: -fno-mrp-warnings` in your cabal-file, [...]

Apropos, is there a similar option for AMP warnings? I would rather use that than CPP.

Sure, added in GHC 7.8: | In GHC 7.10, Applicative will become a superclass of Monad, | potentially breaking a lot of user code. To ease this transition, GHC | now generates warnings when definitions conflict with the | Applicative-Monad Proposal (AMP). | | A warning is emitted if a type is an instance of Monad but not of | Applicative, MonadPlus but not Alternative, and when a local function | named join, <*> or pure is defined. | | The warnings are enabled by default, and can be controlled using the | new flag -f[no-]warn-amp. However, if you use that now with GHC 7.10 you get a warning: | $ ghc-7.10.2 -fno-warn-amp | | on the commandline: Warning: | -fno-warn-amp is deprecated: it has no effect, and will be removed in GHC 7.12 so you you'll need to guard that with something like if impl(ghc == 7.8.*) ghc-options: -fno-warn-amp

2015-10-07 9:35 GMT+02:00 Herbert Valerio Riedel :

Btw, I've also seen the trick below, in which you use the aliased `A.` prefix just once so GHC considers the import non-redundant, and don't have to suffer from prefixed operators in the style of `A.<*>`.

Is this any better? [...]

While not perfect, it's much better than having to fiddle around with Prelude imports. Although there's the slight danger that somebody else (or the author 1 year later) looks at the code and has a WTF-moment... ;-) To be honest, while it's somehow obvious how it works when you read it, I've never seen that trick. Perhaps stuff like this belongs into some general "Porting Guide", along with its alternatives. It's general enough that it should not be buried in some AMP/FTP/return/... transitioning guide. Cheers, S.

On Tue, Oct 6, 2015 at 1:41 PM, Sven Panne wrote:

2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel :

...

[...] That's because -Wall-hygiene (w/o opting out of harmless) warnings

across multiple GHC versions is not considered a show-stopper.

...

That's your personal POV, I'm more leaning towards "-Wall -Werror". I've seen too many projects where neglecting warning over an extended period of time made fixing them basically impossible at the end. Anyway, I think that a sane ecosystem should allow *both* POVs, the sloppy one and the strict one.

Note: You haven't been able to upload a package that has -Werror turned on in the cabal file for a couple of years now -- even if it is only turned on on the test suite, so any -Werror discipline you choose to enforce is purely local. -Edward

Do those participating in this thread think sentiments like this are constructive or inclusive? Is this how we encourage participation from newer members of the community? Framing this debate in terms of a programming pecking order is unprofessional. Many times, those higher in the ranks will prefer a more conservative approach, as experienced surgeons once resisted the introduction of the autoclave. The problem isn't the change; it's what the change costs you. Provide data and make your case. Talk about what it _costs_ you, show evidence for that cost, and describe what would make the change acceptable. Do it without talking down to a constructed "other" of the people who've neglected to make the same status display you've injected into this conversation. That could be valuable input to the discussion, so we would could weigh costs and benefits as a community. There _are_ costs associated with going ahead with MRP, especially for those with large 1mm LOC industrial codebases. This is partly why I'm lukewarm on the change, but I believe it needs to happen sooner or later and waiting for more 1mm LOC codebases to be born isn't going to make it any better. The suggestions that we consider the example of 2to3 I believe have been more constructive, particularly since we have this lovely language which lends itself so nicely to static analysis anyway. On Tue, Oct 6, 2015 at 2:02 PM, Malcolm Wallace wrote:

On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote:

...

...

The problem by discussions is that they are done between two groups with quite a difference in experience. On one hand you have people like

...

...

who have considerable contributions to the Haskell ecosystem and much experience in large scale software development (e.g. from Facebook). On

Bryan, the

...

...

other hand you have people who don't. That's okay. We've all been at the latter group at some point of our career. [...]

At the risk of stating the obvious: I don't think it matters from which group a given argument comes from as its validity doesn't depend on the messenger.

In that case, I think you are misunderstanding the relevance of Johan's argument here. Let me try to phrase it differently. Some people who can reasonably claim to have experience with million-line plus codebases are warning that this change is too disruptive, and makes maintenance harder than it ought to be. On the other hand, of the people who say the change is not really disruptive, none of them have (yet?) made claims to have experience of the maintenance of extremely large-scale codebases. The authority of the speaker does matter in technical arguments of this nature: people without the relevant experience are simply unqualified to make guesses about the impact.

Regards, Malcolm _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Chris Allen Currently working on http://haskellbook.com

On Tue, Oct 6, 2015 at 7:24 PM, Mike Meyer wrote:

I've dealt with the IETF RFC process and the Python PEP process, and both of them worked better than that.

While both those are good examples of mostly working organizations shepherding foundational technical standard(s) along... there is one thing more important than their processes: Their stance. Both organizations have a very strong engineering discipline of keeping deployed things working without change. I don't think it is enough to simply model their process. Until about three years ago, the Haskell community also had such a discipline. It has been steadily eroding over the last few years. - Mark

On Tue, Oct 6, 2015 at 6:18 PM, Gershom B wrote:

With that in mind, I think the _concrete_ voices of concern have been the most useful. Gregory Collins’ list of issues requiring CPP should be very sobering. Of note, I think they point to areas where the core libraries committee has not paid _enough_ attention (or perhaps has not been sufficiently empowered: recall that not all core libraries fall under its maintenance [2]). Things like the newtype FFI issue, the changes to prim functions, the splitup of old-time and the changes to exception code were _not_ vetted as closely as the AMP and FTP were, or as the MRP is currently being. I don’t know all the reasons for this, but I suspect they just somewhat slipped under the radar.

In fact, more often than I would like, I can recall arguing against a particular change https://www.mail-archive.com/ghc-devs@haskell.org/msg02133.html on the grounds that it would break user code, and in Haskell land this is a battle I usually lose. Usually the argument on the other side boils down to expediency or hygiene/aesthetics -- it's *difficult* to engineer a change to some core infra in a way that minimizes impact on people downstream, and it takes a long time. Often "this change is going to cause a small amount of work for all of my users" is something that seems to not be taken into consideration at all. For this particular proposal, every user will have some small amount of work *w* to do (to read the change notes, understand why 'return' is going away, train yourself to use "pure" now instead of "return" like you've been using for 15 years, etc). It might feel like *w* is small and so the change isn't burdensome, but *n* is literally everyone who uses the language, so the total work *w***n* is going to amount to quite a few person-hours. I just want to make sure that everyone is keeping that in mind and weighing that effort against the benefits. Outside of that, the most disruptive changes to my code that I can recall

have been from changes to the aeson library over the years — particularly but not only regarding its handling of doubles. I don’t begrudge these changes — they iteratively arrived at a _much_ better library than had they not been made. [3] After than, I made a few changes regarding Happstack and Snap API changes if I recall. Additionally, the addition of “die” to System.Exit caused a few name clashes. My point is simply that there are many packages outside of base that also move, and “real” users with “real” code will these days often have quite a chain of dependencies, and will encounter movement and change from across many of them. So if we say “base never changes” that does not mean “packages will never break” — it just means that base will not have the same opportunity to improve that other packages do, which will eventually lead to frustration, just as it did in the past and in the leadup to the BBP.

Culturally, we have a problem with library authors of all stripes being too cavalier about breaking user programs: we definitely lean towards "move fast and break things" vs "stay stable and don't make work for users". As you write more and more Haskell code, you depend on more and more of these libraries, and this means that once you go beyond a certain threshold you will be spending a significant amount of your time just running to keep up with the treadmill. Personally I just don't have enough time for writing Haskell code as I used to (or I would like), so I would say for me that the treadmill tax is now probably exceeding 50% of my total hours invested. Greg

On Wed, Oct 7, 2015 at 9:38 AM, Erik Hesselink wrote:

While I don't think it detracts from your argument, it seems you misread the original proposal. At no point will it remove `return` completely. It would be moved out of the `Monad` class and be made into a top-level definition instead, so you would still be able to use it.

Then why bother? If you don't intend to regard code that uses "return" as old, out-dated, in need of updating, etc.... If you don't intend to correct people on #haskell to use pure instead of return... If you don't tsk tsk all mentions of it in books.... If you don't intend to actually deprecate it. Why bother? But seriously, why do you think that "you would still be able to use it"? That is true for only the simplest of code - and untrue for anyone who has a library that defines a Monad - or anyone who has a library that they want to keep "up to date". Do you really want to have a library where all your "how to use this" code has return in the examples? Shouldn't now be pure? Do I now need -XCPP just for Haddock? and my wiki page? And what gets shown in Hackage? This is just a nightmare for a huge number of libraries, and especially many commonly used ones. Why bother!

The part of the MRP proposal that I actively care about because it fixes a situation that *actually causes harm* is moving (>>) to the top level. Why? Right now (*>) and (>>) have different default definitions. This means that code runs often with different asymptotics depending on which one you pick. Folks often define one but not the other. This means that the performance of mapM_ and traverse_ needlessly differ. It means that we can't simply weaken the type constraint on mapM_ and sequence_ to Applicative, it as a knock-on consequence it means we can't migrate mapM and sequence out of Traversable to top level definitions and thereby simply provide folks with more efficient parallelizable mapping when they reach for the 'obvious tool'. return itself lurking in the class doesn't matter to me all that much as it doesn't break anybody's asymptotics and it already has a sensible definition in terms of pure as a default, so effectively you can write code as if MRP was already in effect today. It is a wart, but one that could be burned off on however long a time table we want if we choose to proceed. -Edward On Wed, Oct 7, 2015 at 5:13 PM, Mark Lentczner wrote:

On Wed, Oct 7, 2015 at 9:38 AM, Erik Hesselink wrote:

...

While I don't think it detracts from your argument, it seems you misread the original proposal. At no point will it remove `return` completely. It would be moved out of the `Monad` class and be made into a top-level definition instead, so you would still be able to use it.

Then why bother? If you don't intend to regard code that uses "return" as old, out-dated, in need of updating, etc.... If you don't intend to correct people on #haskell to use pure instead of return... If you don't tsk tsk all mentions of it in books.... If you don't intend to actually deprecate it. Why bother?

But seriously, why do you think that "you would still be able to use it"? That is true for only the simplest of code - and untrue for anyone who has a library that defines a Monad - or anyone who has a library that they want to keep "up to date". Do you really want to have a library where all your "how to use this" code has return in the examples? Shouldn't now be pure? Do I now need -XCPP just for Haddock? and my wiki page? And what gets shown in Hackage? This is just a nightmare for a huge number of libraries, and especially many commonly used ones.

Why bother!

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Sat, Oct 10, 2015 at 4:12 PM, Yuras Shumovich wrote:

On Sat, 2015-10-10 at 15:25 -0400, Edward Kmett wrote:

...

The part of the MRP proposal that I actively care about because it fixes a situation that *actually causes harm* is moving (>>) to the top level.

Sorry if I'm missing something, but moving (>>) is not part of the proposal. At least it is not mentioned on the wiki page:

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

Is the wiki outdated?

It arose during the original thread discussing the MRP but wasn't included in the 'proposal as written' that was sent out. https://mail.haskell.org/pipermail/libraries/2015-September/026129.html In many ways that proposal would do better 'on its own' than as part of the MRP.

return itself lurking in the class doesn't matter to me all that much

...

as it doesn't break anybody's asymptotics and it already has a sensible definition in terms of pure as a default, so effectively you can write code as if MRP was already in effect today. It is a wart, but one that could be burned off on however long a time table we want if we choose to proceed.

So the cost of not moving `return` to the top level is zero?

For me the cost of moving it is pretty small, just an hour or two. Probably recompiling all the dependencies when switching to newer version of GHC will take longer. (Actually I'm still using 7.8 at work.) But the cost is definitely nonzero.

The proposal (as written on the wiki page) provides two arguments for the change:

There is no reason to include `return` into the next standard. That is true.

Nobody is saying that we should remove return from the language. The proposal was to move it out of the class -- eventually. Potentially on a very very long time line. But we can leave `return` is `GHC` as a compiler specific extension for

backward compatibility, can't we?

This is effectively the status quo. There is a default definition of return in terms of pure today. The longer we wait the more tenable this proposal gets in many ways as fewer and fewer people start trying to support compilers versions below 7.10. Today isn't that day. There are some niggling corner cases around viewing its continued existence as a compiler "extension" though, even just around the behavior when you import the class with Monad(..) you get more or less than you'd expect. Could someone please clarify what is the cost of not moving `return` out of

`Monad`?

The cost of doing nothing is maintaining a completely redundant member inside the class for all time and an ever-so-slightly more expensive dictionaries for Monad, so retaining return in the class does no real harm operationally. While I'm personally somewhat in favor of its eventual migration on correctness grounds and believe it'd be nice to be able to justify the state of the world as more than a series of historical accidents when I put on my libraries committee hat I have concerns. I'm inclined to say at the least that IF we do decide to proceed on this, at least the return component should be on a long time horizon, with a clock tied to the release of a standard, say a Haskell2020. I stress IF, because I haven't had a chance to go through and do any sort of detailed tally or poll to get a sense of if there is a sufficient mandate. There is enough of a ruckus being raised that it is worth proceeding cautiously if we proceed at all. -Edward