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

Tue Jan 3 22:59:15 UTC 2017

I know about fmap :) And, sure, I agree that better pedagogy (and
careful library design) can make typesafe programming pleasant in some
cases – but not all, and not even enough to make me stop worrying about
the rest of them. (I've been using Haskell for eight years by now and I
can't call the experience “breezing along with the top down in your sexy
typesafemobile”, not really.)

On 01/04/2017 01:37 AM, Theodore Lief Gannon wrote:
> 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
> <mailto: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 <mailto: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 <mailto:Libraries at haskell.org>
>>         http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>         <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
>>
>>
>>
>>
>>     _______________________________________________
>>     Libraries mailing list
>>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
>     _______________________________________________ Libraries mailing
>     list Libraries at haskell.org <mailto:Libraries at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170104/2d78f33e/attachment.html>