<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 9, 2014 at 5:29 PM, Artyom Kazak <span dir="ltr"><<a href="mailto:yom@artyom.me" target="_blank">yom@artyom.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
On 01/10/2014 04:17 AM, John Lato wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I think this is a really important point.  If I may go further, it's arguable that 'type String = [Char]' was a poor decision, and one of the arguments is that it's not possible to make different instances for String and [a] (hence the showsList issue).<br>

</blockquote></div>
Actually, I think it’s an instance of a bigger problem: *newtypes aren’t as transparent as they should’ve been*. The very first thing a beginner is told about newtypes is that they bear no additional runtime cost at all – which, in fact, hasn’t been strictly true until the recent introduction of Roles – but the first thing they learn *by theirself* is that newtypes are only “free” for the computer, not for the programmer!<br>

<br>
Imagine an alternative Prelude in which `String` is a newtype for `[Char]` and not a type synonym: you wouldn’t be able to `map` over it without deconstructing it first, or `reverse` it, or even compute its `length`... And having to type `f (Str s)` instead of `f s` would already discourage people enough that most of them would be trying to avoid Strings, even if only subconsciously.<br>

<br>
General tendency to follow the path of least resistance is probably the reason why newtypes aren’t used as often as they should be. Have there been any proposals aiming to solve this issue? (A quick search didn’t bring up anything, but maybe I was just searching for a wrong thing.)<br>

</blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">The programmer overhead from newtypes is greater than I would like, even as minimal as it is.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
I find that using isomorphisms from the lens package goes a long way to reducing the programmer overhead from using newtypes.  I recently did a very lens-heavy project, and I found that the ease of working with newtype'd values via isomorphisms made me much more likely to define newtypes in the first place.  So that's one solution, YMMV.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Of course, that's assuming that String would just be a newtype instead of a type alias.  If it were an actual abstract type, then we couldn't use map/fmap at all.  However, we've had type class based solutions for that problem for some time now, e.g. the ListLike package, and newer alternatives like mono-traversable.  (Incidentally, I've been toying with the idea of making ListLike depend on mono-traversable.  It would basically just be an API re-skinning, plus we could have more efficient definitions of some functions).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">An abstract String would also be better than our current situation because Data.List functions on Strings are just plain wrong anyway.  Simple example: what should be the reverse of "This is two lines\r\nbecause Windows!\r\n"?  It gets even more fun with unicode.  Oddly, I was just looking at <a href="http://msmvps.com/blogs/jon_skeet/archive/2009/11/02/omg-ponies-aka-humanity-epic-fail.aspx">http://msmvps.com/blogs/jon_skeet/archive/2009/11/02/omg-ponies-aka-humanity-epic-fail.aspx</a> 10 minutes ago.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">(Of course if String were properly abstract, you could still define an isomorphism between String and [Char] somehow.  And somewhere in Turkey a tier-1 techie cries out...)</div>
</div>