On Thu, Dec 29, 2016 at 4:47 PM, Bardur Arantsson <spam@scientician.net> wrote:
On 2016-12-29 21:12, Andreas Abel wrote:
>
> I am in favor of deprecating "read" and pointing to a total version in a
> library.  Otherwise, I'd leave the Prelude unchanged.
>

But that throws a wrench in the works of people who want to be "-Wall"
clean... unless you mean "deprecated" in the sense of being *documented*
as deprecated rather than actually marked as such (causing deprecation
warnings during compilation).

Indeed. 

I'm not sure actually... do we have fine-grained deprecation warnings
yet?[1]

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.
 
I.e. can we turn on/off individual deprecation warnings with
compiler switches? If so, then just deprecating read and pointing to a
readMaybe in some module might be the optimal solution here.
 
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.

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.

[1] If we don't then I honestly think that this may be the single most
important feature to be able to move forward wrt. the Prelude. (Well, a
"go fix" type tool might be even better, but that's not likely to happen
any time soon.)

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.

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.

I do think if we're going to include readMaybe there isn't much point in not including the slightly more powerful readEither.

-Edward

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