<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>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 <span style="font-family:sans-serif">with the top down</span> in
your sexy typesafemobile”, not really.)</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 01/04/2017 01:37 AM, Theodore Lief
Gannon wrote:<br>
</div>
<blockquote
cite="mid:CAJoPsuAi-+WzwFjNaQvisW_xb6L1k3mSK0j1=QF1cmOAWwAkrg@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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
moz-do-not-send="true" 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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Libraries@haskell.org"
target="_blank">Libraries@haskell.org</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true" class="m_-879965222415765616moz-txt-link-abbreviated" href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>
<a moz-do-not-send="true" 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>
</div>
______________________________<wbr>_________________
Libraries mailing list
<a moz-do-not-send="true" href="mailto:Libraries@haskell.org">Libraries@haskell.org</a>
<a moz-do-not-send="true" 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>
</blockquote></div></div>
</blockquote>
</body></html>