Proposal: Add readMaybe (and possibly readEither) to Prelude, make Haddocks for read more cautionary

Artyom yom at
Tue Jan 3 21:40:58 UTC 2017

I'm +1 on improving the documentation of `read`. The current description
(“which must be completely consumed by the input process”) is pretty bad.

I'm +0.5 on adding `readMaybe` and `readEither` to Prelude.

I'm -1 on actually deprecating `read`, even if we do provide a safe
replacement in the Prelude.


While removing partial functions aids safety, it also makes the language
burdensome and unpleasant to use. Sure, for experienced programmers it
might not matter – they have much bigger challenges to overcome, and
adding some imports or handling an error takes much less time than
debugging a program that is failing because someone else used a partial
function somewhere in the middle of code.

However, not everyone is an experienced programmer and not everyone is
solving Real-World Problems with Haskell. Some people just want to have
fun when they are programming, and maybe get something useful as a
result. In my experience, nothing kills fun better than having to unwrap
and chain Maybes, add dozens of imports, insert `error`s and so on
whenever you don't care about failure, etc etc etc.

If Haskell gains reputation as an incredibly safe language, yeahwe'll
likely see lots of beginners who would want to learn and use Haskell
anyway even if it's not that fun; and if we as a community decided to go
this way, I would've voted differently, as I would've evaluated the
proposal from a different point of view (“whether or not it makes the
language safer”). However, as long as we all *haven't* agreed that
safety is more important than fun, I'm going to optimise for an outcome
which I personally prefer, and leave the “safety above all else” goal to
other languages.

My personally preferred outcome – i.e. what I want Haskell to be – is a
language that is fun to use while still being *possible* to make safe if
needed. Thus, I'm glad that newtypes exist and can be used without that
much effort. I'm glad that alternative preludes that ban partial
functions could be written. I'm glad that qualified imports exist, and I
also think it would be good if there was a GHC flag banning unqualified
imports. I'm glad that phantom types, type families, etc all exist and
are helping people write safe code that they wouldn't be able to write

Howevev, what I feel really strongly about is that such things should
not be the default. It's good that a professional Haskeller (or a team
of Haskellers, or a Haskell shop, etc) can enforce safety standards if
they want to, and it's good that with Haskell it's easier than with
other languages, but why should those standards be forced on *all*
Haskellers? Contrary to what some might believe, safety is not an
ultimate goal of every Haskeller (an example being myself). I'm fine
with my code failing every now and then, because the alternative is that
it might not get written at all as I get tired of fighting the compiler
and the Prelude.

If my preferences are deemed bad/invalid/perverse by the community, or
if I'm simply an outlier (as we might determine by doing a survey), or
if it turns out that nobody else out there hates handling error cases
manually and unwrapping Maybes, then sure, let's deprecate all partial
functions. However, if I'm not an outlier, then I'd rather see Haskell
move in such a direction that makes it easier for hobbyists to write
code *and* easier for professionals to write *safe* code. Deprecating
`read` is a move in the opposite direction – it makes hobbyists' lives
harder while not changing anything for professionals (because half of
them probably uses an in-house or alternative Prelude and another half
can just grep for calls to `read` during the continuous integration build).


On 01/03/2017 11:26 PM, Tom Murphy wrote:
> I'm -1 on deprecating read if we don't provide a safe replacement in
> the Prelude.
> Tom
> On Tue, Jan 3, 2017 at 1:40 PM, Mario Blažević <mblazevic at
> <mailto:mblazevic at>> wrote:
>     On 2017-01-03 09:17 AM, David Feuer wrote:
>         While I don't often agree with Henning, it seems that the
>         notion of
>         (quasi?)deprecating read is somewhat more popular than the
>         notion of
>         adding replacements for it.
>     I haven't spoken so far, but that's also my impression and my
>     preference as well.
>     _______________________________________________
>     Libraries mailing list
>     Libraries at <mailto:Libraries at>
>     <>
> _______________________________________________
> Libraries mailing list
> Libraries at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list