Dear Edward and Core Libraries Committee Can you tell us what plan you want to execute for MonadFail? Specifically, in https://wiki.haskell.org/MonadFail_Proposal · Is the specification in 1.3 what you have agreed? · Is the transition strategy in 1.7 exactly what you want? We can’t implement 8.0 without being sure of the specification! The current Phab is https://phabricator.haskell.org/D1248 Also, David, did our conversation at HX help you get un-stuck? Thanks Simon From: haskell-core-libraries@googlegroups.com [mailto:haskell-core-libraries@googlegroups.com] On Behalf Of Edward Kmett Sent: 13 October 2015 01:43 To: core-libraries-committee@haskell.org Subject: [core libraries] Prelude: 3 Release Policy Recently there has been a bunch of chatter about ways to mitigate the amount of CPP pushed on users by changes to the Prelude. In particular the discussion has been around the idea of trying to ensure that it is possible to write code in _some_ way without CPP that can run backwards for 3 releases of GHC, preferably in a -Wall safe manner. The approach they may have to use may not be the idiomatic way, but in general it should exist. Gershom ran around at the Haskell Exchange sounding folks out about this idea, and it seems to codify a reasonable tension between the "change nothing" and "change everything" camps. The feedback thus far seems to be noises of "grumbling acceptance" rather than the current state of outright panic that we might do anything at any time. I'm personally considering this a very high priority for all changes to Prelude going forward. The 3 years forms a backward-facing window, not a guarantee against future change, but we should of course try to let folks know what is coming with a decent time horizon so folks can look forward as well. That is a separate concern, though. I'm not ready to give the "3 release policy" outright veto power over new functionality, but at least if we have two plans that can in the end yield the same end state, we should definitely err on the side of the plan that falls within these guidelines, and be very well ready to explain to a rather irate community when we violate this rubric. It shouldn't be done lightly, if at all, if we can help it! All in all it is a fairly weak guarantee, but it does have some impact on current items under consideration. Off the top of my head: * A number of new members for Floating were passed by proposal back before 7.10 went out the door, but haven't found their way into base yet: expm1, log1p, etc. are absolutely required for decent precision numerics. When the proposal passed we ultimately decided _not_ to include default definitions for these to force authors to implement them explicitly. Under the guidelines here, the plan would likely have to include default definitions for these to start when introducing them in 8.0. Then in 8.4 we could in theory remove the defaults and remain in compliance with the letter of the law here or introduce an ad hoc warning about lack of implementation, and remove the defaults in 8.6, depending on how gradual an introduction we wanted to give. We wouldn't be able to do the warnings in 8.2, however, and remain within the letter of the law, and we wouldn't be able to introduce them without defaults without violating the no-warnings guideline. * MonadFail reform proposal wouldn't be able to start issuing warnings about missing instances until 8.4 even if we put in MonadFail into a module today. This would likely delay the full implementation of the proposal to 8.6 as well. * The Semigroup as a superclass of Monoid proposal runs into a similar clock. An immediate consequence is that creating a class in base (or moving one into base) and moving it into Prelude changes picks up a 3-4 year window for implementation. (3 years from this guideline, and a year if we want to / should give warnings about missing instances, which as mentioned above, is a separate concern.) Observations: This doesn't imply the lack of warnings for new names coming into Prelude, because code can be changed to use the new names in a backwards compatible way. The AMP warnings would be in compliance. I don't think we can viably apply this reasoning to other modules in base or even most other packages under the core libraries purview: It'd be nice, but things like template-haskell change on too quick a clock. For other modules in base or other libraries in scope of the core libraries process, I'd probably consider this guideline demoted from "should" to "may". When Data.Proxy or Data.Void were brought into base they were brought in more or less unmolested from tagged and void respectively with only minor differences. This means that code that wants to use them with older versions of the compiler can use their pre-existing dependency as a conditional (or mandatory) listed dependency. This means that code that was using them before continues to work fine despite their incorporation into base. Compliance with this rule also acts as a hedge against severe bikeshedding when we incorporate more stuff. In the case of Semigroup you can use the semigroups package today in a form that is backwards compatible for a half dozen We could ship a 'fail' package that gave you access to the MonadFail class across older GHC versions. The question then becomes is it worth trying to use the existence of those packages to try to "cheat the clock"? I think we'd almost assuredly be rightly called out for 'cheating' by package maintainers where a fresh 'fail' package was concerned, but given the widespread distribution of 'semigroups' it might be plausible to use that to justify finishing out that proposal in 8.4 (end of 2017) rather than 8.6 (end of 2018). Personally, I'm content with the longer clock and don't think it'd be worth doing in this case, but it was an informative exercise to consider. At the least, the existence of such packages lets us go much farther back than 3 releases for folks who have a wider support window. Again, the above guideline would basically imply that if you wanted to add a thing to base and get it into the Prelude you can't do it in less than 3 years. Given the stability of Prelude this is the _least_ we can do. Now nobody needs to worry about us rushing off to add Pointed or Semiapplicative to Prelude in the short term. It simply can't move into base and happen that fast. Things already in base could admittedly take a shorter path and comply, but it is worth noting that this is just one guideline -- both the AMP and Foldable/Traversable Proposal would pass this litmus test. I'm mostly just running through active proposals and trying to understand the impact of such a policy, but so far I can't find anything that causes me to object. I'm content to codify it as my own personal "best practice", and would be willing to see us as an organization draft it up into a form that other people could rely upon to get a sense of stability. In all of the above cases I think it actually improves upon the timeline a bit. Lengthening the timelines above means we'll need to work harder on transferring institutional memory at the very least. Wiki and Trac items for these sorts of proposals will become even more important. It will become almost impossible to spawn a from-scratch Prelude-affecting proposal and finish it during one 3-year cycle tenure on the committee. Ideas? -Edward -- You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe@googlegroups.commailto:haskell-core-libraries+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optouthttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgroups.google.com%2fd%2foptout&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c2b0f672ddfdd4b3fd55208d2d3673d17%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BaJtRHAFWowT0t5EOfmrS%2f5PAdWpnv2VN82LxMMJOgA%3d.