<div dir="ltr"><div>From the discussion so far, feedback seems overwhelmingly positive on making the change, so everything I say here just assumes we're going forward.<br><br>The way I see it there are two rough options:</div><br>Option 1.) We could just add them directly in the next major release. The downside is that then there is no warning period for folks to deal with any (unlikely as they might be) name collisions. On the other hand, such collisions are going to be readily obvious as to how to fix.<div><br></div><div>Option 2.) Or we could go with making the next major GHC release have a warning about those names and the following major release have the Prelude change. This would fit with the behavior of the AMP towards most names, and fit with the behavior of the existing CLC changes that we have in progress over the next few years. The downside is that this then requires someone to hack up some code in GHC to issue the warning about pending names.</div><div><br></div><div>Given the relative obscurity of the names here I'm less worried about this than I'd otherwise be but embracing the AMP-like approach for consistency might calm some fears of rampant Prelude-changes.</div><div><br><div>By "next GHC release" I'm being a bit vague, because if we went with Option 2 it'd be down to how quickly that code could get written and if GHC HQ wants to make such changes for 8.2 at this time. We're getting close to release candidate time, but on the other hand, it is a pretty straightforward change.</div><div><br></div><div>This gives a time table of somewhere between the extremes of doing it in 8.2 next month, assuming we decide to just rip the bandaid off and merge, and 8.6 if we don't get warnings in for 8.2 and have to warn in 8.4 and take the names in 8.6.</div><div><br></div></div><div><div>Off the cuff I don't particularly care which way we proceed and I am very much open to feedback about which way we should jump.</div><div><br></div></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 2, 2017 at 10:10 AM, Simon Jakobi <span dir="ltr"><<a href="mailto:simon.jakobi@googlemail.com" target="_blank">simon.jakobi@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">2016-12-30 5:51 GMT+01:00 Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>>:<br>
> I'm a weak +1 on adding re-export of the existing readMaybe and readEither<br>
> to the Prelude, possibly after a warning period.<br>
<br>
</span>What would such a warning period look like? Does it simply mean that<br>
there is an announcement on the Haskell mailing lists "Heads up, we'll<br>
add readMaybe and readEither to the Prelude in base-4.11"?<br>
<span class=""><br>
> They are sufficiently<br>
> obscure names that I'm personally not expecting many name conflicts at all<br>
<br>
</span>There are quite a few packages [1] that define their private version<br>
of readMaybe, but I don't think that these should be counted as<br>
arguments _against_ adding the function to Prelude.<br>
<br>
Simon<br>
<br>
[1] <a href="https://github.com/search?l=Haskell&q=readMaybe&type=Code" rel="noreferrer" target="_blank">https://github.com/search?l=<wbr>Haskell&q=readMaybe&type=Code</a><br>
</blockquote></div><br></div>