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

Tue Jan 3 22:37:00 UTC 2017

I consider it a massive failing of Haskell's communal pedagogy that you're
unwrapping Maybe often enough that it feels burdensome. That's what fmap is
for.

I'm not being flip, here. This came up just yesterday on reddit -- in
presenting a solution to a problem, fromJust was used, along with a
disclaimer about how it's unsafe and only there to avoid complicating the
example with error handling. I responded with a version that fmap'd over
the Maybe instead of unwrapping it at all: it was a hair shorter, and no
more complex.

I knew I *could* fmap over Maybe after my first functor tutorial, but
connecting the dots to realize that it's what I *should* do wherever it's
an option took me a lot longer than it should have, and I'm clearly not
alone in that. This is a damn shame, because it represents the difference
between wrestling with types to get the benefits of safety vs. breezing
along with the top down in your sexy typesafemobile.

[1] https://redd.it/5lj45c

On Jan 3, 2017 1:40 PM, "Artyom" <yom at artyom.me> wrote:

> 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.
>
> <rant>
>
> 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 otherwise.
>
> 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).
>
> </rant>
> 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 stilo.com>
> 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 haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
>
> _______________________________________________
> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170103/976e5cf6/attachment-0001.html>