<div dir="ltr"><div>On Sun, Aug 25, 2013 at 2:29 PM, Henning Thielemann <span dir="ltr"><<a href="mailto:schlepptop@henning-thielemann.de" target="_blank">schlepptop@henning-thielemann.de</a>></span> wrote:<br></div>
<div class="gmail_extra"><div class="gmail_quote"><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">Am <a href="tel:25.08.2013%2017" value="+12508201317" target="_blank">25.08.2013 17</a>:13, schrieb Edward Kmett:<div class="im">
<br>
<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">
Looks like that takes us back to the original proposal.<br>
</blockquote>
<br></div>
It seems that both of Edward and my proposal have a drawback:<br>
Edward's proposal restricts lists to [Char].<br>
My proposal allows more element types, but type inference fails for (length "abc").<br>
<br>
Why is it necessary to let (length "abc") work as is?<br></blockquote><div><br></div><div>The issue is that length "abc", splitAt 2 "abc", and dozens of other tools just stop working for anyone who turns on OverloadedStrings right now.<div>
<br></div><div>These users tend to be the users who are most vulnerable from the standpoint of not knowing what is happening to them. They just see that Haskell "doesn't work" and go back to Ruby.</div><div>
<br></div><div>IsString was originally put forth as a convenience to make string literals work with Text, ByteString, directly as a parsing combinator, or as a variable name or string type in an expression language, but presently that functionality comes at the tax that random other bits of code in your file stop working when you turn it on.</div>
<div><br></div><div>My proposal is intended to address this fact, by giving up a subset of possible convenience instances in exchange for fixing the real headache this induces for users.</div><div><br></div><div>I offer as an example the fact that this even bit us in <font face="courier new, monospace">lens</font> due to the ubiquitous use of <font face="courier new, monospace">doctest</font> throughout the package. We have to put explicit <font face="courier new, monospace">:set -XNoOverloadedStrings</font> at the top of any <font face="courier new, monospace">$setup</font> block that uses a string as an example, because we chose in 2-3 modules to turn on OverloadedStrings to better showcase how to work with the text and bytestring lenses. doctest per force recycles the same ghc-api session, as otherwise it takes many many times longer to run. Every once in a while someone has built a different subset of the modules in a different order, and we find out we forgot to turn it off in yet another place. The alternative is that we clutter literally a few hundred doctests with embedded <font face="courier new, monospace">:: String</font> type annotations obscuring the very thing they were put in to teach. This was even worse before we got Simon Hengel to add support for <font face="courier new, monospace">$setup</font><font face="arial, helvetica, sans-serif"> blocks!</font></div>
<div><br></div><div>-Edward</div></div><div><br></div><div> </div><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">
Would (length ("abc" :: String)) be too complicated?<br>
<br>
</blockquote></div><br></div></div>