<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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 <span style="font-family:sans-serif">with the top down</span> in your sexy typesafemobile.</div><div dir="auto"><br></div><div dir="auto">[1] <a href="https://redd.it/5lj45c">https://redd.it/5lj45c</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Jan 3, 2017 1:40 PM, "Artyom" <<a href="mailto:yom@artyom.me">yom@artyom.me</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
I'm +1 on improving the documentation of `read`. The current
description (“which must be completely consumed by the input
process”) <span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);display:inline!important;float:none"></span>is pretty
bad.
<p>I'm +0.5 on adding `readMaybe` and `readEither` to Prelude.</p>
<p>I'm -1 on actually deprecating `read`, even if we do provide a
safe replacement in the Prelude.</p>
<p><rant><br>
</p>
<p>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.<br>
</p>
<p>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.</p>
<p>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.<br>
</p>
<p>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.</p>
<p>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.<br>
</p>
<p>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).<br>
</p>
<p></rant><br>
</p>
<div class="m_-879965222415765616moz-cite-prefix">On 01/03/2017 11:26 PM, Tom Murphy
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>I'm -1 on deprecating read if we don't provide a safe
replacement in the Prelude.<br>
<br>
</div>
Tom<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Jan 3, 2017 at 1:40 PM, Mario
Blažević <span dir="ltr"><<a href="mailto:mblazevic@stilo.com" target="_blank">mblazevic@stilo.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 2017-01-03 09:17 AM, David Feuer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
While I don't often agree with Henning, it seems that
the notion of<br>
(quasi?)deprecating read is somewhat more popular than
the notion of<br>
adding replacements for it.<br>
<br>
</blockquote>
<br>
</span>
I haven't spoken so far, but that's also my impression and
my preference as well.
<div class="m_-879965222415765616HOEnZb">
<div class="m_-879965222415765616h5"><br>
<br>
______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">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-bi<wbr>n/mailman/listinfo/libraries</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="m_-879965222415765616mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
Libraries mailing list
<a class="m_-879965222415765616moz-txt-link-abbreviated" href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>
<a class="m_-879965222415765616moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a>
</pre>
</blockquote>
<br>
</div>
<br>______________________________<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>
<br></blockquote></div></div>