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

On 2015-10-06 at 19:41:51 +0200, Sven Panne wrote:

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

...

[...] That being said, as how to write your Monad instances today with GHC 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This *does* work (admittedly for an easy example, but this can be generalised):

--8<---------------cut here---------------start------------->8--- module MyMaybe where

import Control.Applicative (Applicative(..)) import Prelude (Functor(..), Monad(..), (.)) -- or alternatively: `import qualified Prelude as P` [...] --8<---------------cut here---------------end--------------->8---

This example above compiles -Wall-clean and satisfies all your 3 stated requirements afaics. I do admit this probably not what you had in mind.

OK, so the trick is that you're effectively hiding Applicative from the Prelude (which might be a no-op). This "works" somehow, but is not satisfactory IMHO for several reasons:

[...] 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? --8<---------------cut here---------------start------------->8--- import Control.Applicative as A (Applicative(..)) data Maybe' a = Nothing' | Just' a instance Functor Maybe' where fmap f (Just' v) = Just' (f v) fmap _ Nothing' = Nothing' instance A.Applicative Maybe' where pure = Just' f1 <*> f2 = f1 >>= \v1 -> f2 >>= (pure . v1) instance Monad Maybe' where Nothing' >>= _ = Nothing' Just' x >>= f = f x return = pure -- "deprecated" since GHC 7.10 --8<---------------cut here---------------end--------------->8--- -- hvr

On Wed, Oct 7, 2015 at 3:35 AM, Herbert Valerio Riedel wrote:

--8<---------------cut here---------------start------------->8--- import Control.Applicative as A (Applicative(..))

data Maybe' a = Nothing' | Just' a

instance Functor Maybe' where fmap f (Just' v) = Just' (f v) fmap _ Nothing' = Nothing'

instance A.Applicative Maybe' where pure = Just' f1 <*> f2 = f1 >>= \v1 -> f2 >>= (pure . v1)

instance Monad Maybe' where Nothing' >>= _ = Nothing' Just' x >>= f = f x

return = pure -- "deprecated" since GHC 7.10 --8<---------------cut here---------------end--------------->8---

Alternately, import Control.Applicative import Prelude data Maybe' a = Nothing' | Just' a instance Functor Maybe' where fmap f (Just' v) = Just' (f v) fmap _ Nothing' = Nothing' instance Applicative Maybe' where

-- hvr _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

On Tue, Oct 6, 2015 at 3:02 PM, Malcolm Wallace wrote:

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

...

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.

Very well. Let me offer a view from the "other side of the fence." I personally maintain about 1.3 million lines of Haskell, and over 120 packages on hackage. It took me less than a half a day to get everything running with 7.10, and about two days to build -Wall clean. In that first day I actually had to spend vastly more time fixing things related to changes in Typeable, template-haskell and a tweaked corner case in the typechecker than anything AMP/FTP related. In the end I had to add two type signatures. Most of the patches to go -Wall clean looked like +#if __GLASGOW_HASKELL__ < 710 import Control.Applicative import Data.Monoid +#endif Maybe 10% were more complicated. -Edward

There's been a lot of complaints about the way things have worked in the past, with things going to fast, or to slow, or the right people not being heard, or notices not going to the right places, etc. As far as I can tell, the current process is that someone make a proposal on some mailing list, that gets debated by those who find out about it, maybe a wiki page gets set up and announced to those who already know about the proposal, and then it either happens or not. There's actually quite a bit of experience with dealing with such. I've dealt with the IETF RFC process and the Python PEP process, and both of them worked better than that. So I think we can do better. I'd like to suggest we adapt something a bit more formal that any process that changes a developer-visible API should have to go through. Note that bug fixes, most security fixes, and other things that don't change the API wouldn't be subject to this requirement. However, any change in an API, even one that's 100% backward compatible, not possibly breaking any code, would be. Initial thoughts on scope are anything in the Haskell Platform, as that seems to be a minimal definition of "Haskell ecosystem". Further, anything on hackage should be able to avail itself of the process. My concrete, though very broad proposal, with lots of details to be filled in yet, is that we need: 1) A wiki page that lists all proposals being considered, along with their current status and other relevant information. 2) A set of requirements a proposal must meet in order to be listed on that page. 3) An announcements list that only has announcements of things being added to the list. Anybody who has time to vote on a proposal should have time to be on this list. 4) An editorial group responsible for maintaining the list and providing guidance on meeting the requirements to get on it. The first three are easy. The fourth one is the killer. Somebody to do the work is the stumbling block for most proposals. This doesn't require deep technical knowledge of Haskell or the current ecosystem, but the ability to implement a process and judge things based on form and not content, Since it's my proposal, I'll volunteer as the first editor. Hopefully, others with better reputation will alsob e available. If adopted, the first two things on the list need to be a description of the process, followed shortly by a description of the requirements to be met.

On Wed, Oct 7, 2015 at 1:45 AM Mark Lentczner wrote:

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.

Well, until Python 3, anyway. My goal wasn't to recreate the engineering discipline that deployed things keep working without change as you upgrade the ecosystem, it's to provide a mechanism so the community can more easily engage with the evolution of the ecosystem. Hopefully this will make it easier for the community to move things forward in a desirable manner. But it's a process, and leaves the question of whether the desire is for more stability or a less stagnant language up to the users of the process. I don't necessarily want to model the IETF or PEP processes. Those are a starting point. I tried to abstract the initial points out enough that the final result could be either one of them, or something totally unrelated that's a better fit for the Haskell community.

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