<div dir="ltr">If Ian can make defaulting work, then I'd prefer that solution. It hurts nobody and just makes everything work better.<div><br></div><div><font face="courier new, monospace">length</font> was just the most galling example among many. </div>
<div><br></div><div>The resolution to Ian's suggestion would absolutely affect just how liberal we want to be with generalizing more of the list combinators to Foldable/Traversable.</div><div><br></div><div>There are a lot of desiderata to consider in balancing the needs of base. </div>
<div><br></div><div>Forcing the only list based instance to be String is an arbitrary decision, but it fixes the vast majority of the issues with a typeclass and extension that was intended to be a convenience but currently causes a great deal of incovenience in otherwise unrelated code when you turn it on.</div>
<div><br></div><div>Having base export two randomly different versions of the same combinator all over the place is also an inconvenience and fixing it comes with some tension towards <font face="courier new, monospace">OverloadedStrings.</font></div>
<div><font face="courier new, monospace"><br></font></div><div><font face="arial, helvetica, sans-serif">Forcing users to use signatures on every </font><font face="courier new, monospace">String</font><font face="arial, helvetica, sans-serif"> and </font><font face="courier new, monospace">import Data.Traversable</font><font face="arial, helvetica, sans-serif"> and </font><font face="courier new, monospace">Data.Foldable</font><font face="arial, helvetica, sans-serif"> qualified "works," but it is the design equivalent of sticking your head in the sand and pretending their we don't have any problems.</font></div>
<div><font face="courier new, monospace"><br></font></div><div>-Edward<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 26, 2013 at 12:33 PM, Henning Thielemann <span dir="ltr"><<a href="mailto:schlepptop@henning-thielemann.de" target="_blank">schlepptop@henning-thielemann.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am <a href="tel:25.08.2013%2023" value="+12508201323" target="_blank">25.08.2013 23</a>:02, schrieb Edward Kmett:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
The issue is that length "abc", splitAt 2 "abc", and dozens of other<br>
tools just stop working for anyone who turns on OverloadedStrings right now.<br>
<br></div><div class="im">
IsString was originally put forth as a convenience to make string<br>
literals work with Text, ByteString, directly as a parsing combinator,<br>
or as a variable name or string type in an expression language, but<br>
presently that functionality comes at the tax that random other bits of<br>
code in your file stop working when you turn it on.<br>
<br>
My proposal is intended to address this fact, by giving up a subset of<br>
possible convenience instances in exchange for fixing the real headache<br>
this induces for users.<br>
</div></blockquote>
<br>
What you propose is, to let the compiler infer: "If it is something string-like (imposed by the string literal syntax in the presence of OverloadedStrings) and it is a list (imposed by 'length'), then it must be a String".<br>
<br>
This conclusion looks rather arbitrary to me. If 'length' would be more specific (e.g. Text.length) your problem would not arise. If 'length' would be more generic (e.g. Foldable.length) your proposal would not help. The problem only arises, because you want to use Prelude's list functions (_and_ OverloadedStrings _and_ don't want to write type annotations).<br>
<br>
I predict that soon people will propose here on this mailing list to replace Prelude's half-monomorphic 'length' by a fully polymorphic Foldable.length. It does not yet exist, but it could be added easily. What will you do then?<br>
<br>
</blockquote></div><br></div>