<div dir="ltr"><div>On Thu, Dec 29, 2016 at 4:47 PM, Bardur Arantsson <span dir="ltr"><<a href="mailto:spam@scientician.net" target="_blank">spam@scientician.net</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 2016-12-29 21:12, Andreas Abel wrote:<br>
><br>
> I am in favor of deprecating "read" and pointing to a total version in a<br>
> library.  Otherwise, I'd leave the Prelude unchanged.<br>
><br>
<br>
</span>But that throws a wrench in the works of people who want to be "-Wall"<br>
clean... unless you mean "deprecated" in the sense of being *documented*<br>
as deprecated rather than actually marked as such (causing deprecation<br>
warnings during compilation).<br></blockquote><div><br></div><div>Indeed. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm not sure actually... do we have fine-grained deprecation warnings<br>
yet?[1] </blockquote><div><br></div><div>We do not. There has been some work on breaking up the monolithic set of warnings and being a bit more regular about how we handle them, but not individual groups of deprecations.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I.e. can we turn on/off individual deprecation warnings with<br>
compiler switches? If so, then just deprecating read and pointing to a<br>
readMaybe in some module might be the optimal solution here.<br></blockquote><div> </div><div><div>I'm strongly -1 on adding a full-fledged DEPRECATED flag to read. The amount of noise that would generate would dwarf anything else under discussion by multiple orders of magnitude. It is in the Haskell Report and it has been used a lot for a couple of decades now.<br><br>On the other hand, whether or not anything changes in Prelude, I'm a strong +1 on adding documentation to it that mentions these safer alternatives, and where to get them if necessary.<br></div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[1] If we don't then I honestly think that this may be the single most<br>
important feature to be able to move forward wrt. the Prelude. (Well, a<br>
"go fix" type tool might be even better, but that's not likely to happen<br>
any time soon.)</blockquote><div><br></div><div>The amount of CPP running around in Haskell with any sort of long support window makes 'go fix' tools quite shockingly difficult for us to get right.</div><div><div><br class="gmail-Apple-interchange-newline">I'm a weak +1 on adding re-export of the existing readMaybe and readEither to the Prelude, possibly after a warning period. They are sufficiently obscure names that I'm personally not expecting many name conflicts at all and the changes in base are minimal as the classes and 'read' are already re-exports from the same place, so there isn't much of an engineering challenge.</div><div><br></div><div>I do think if we're going to include readMaybe there isn't much point in not including the slightly more powerful readEither.</div><div><br></div><div>-Edward</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">
______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div></div>