<div dir="ltr">May I propose an alternative solution? Why not just add a syntactic way to selectively opt in or out of `OverloadedStrings` for certain string literals? It could be something as simple as Python's trick for prefixing string literals with a single character to either enable or disable the overloading:<div>
<br></div><div><font face="courier new, monospace"> example1 :: Int</font></div><div><font face="courier new, monospace"> example1 = length "Non-overloaded string"</font></div><div><font face="courier new, monospace"><br>
</font></div><div><font face="courier new, monospace"> example2 :: Parser Int</font></div><div><font face="courier new, monospace"> example2 = o"Overloaded string" *> pure 4</font></div><div><br></div><div>
... but it doesn't have to be that specific solution. All that really matters is that it is syntactically lightweight.<div><br></div><div>I would personally prefer "opt-in" that way you could safely turn on `OverloadedStrings` in any module without errors and then use whatever syntactic annotation when you want to overload a particular string.<div>
<br></div><div>The reason I propose this solution is that I foresee the exact same problem occurring later on for `OverloadedLists` where you will get ambiguous type errors any time you pass a list literal to a function of `Foldable`s. Similarly, in that case it would also be nice to be able to selectively opt in or out of overloaded list literals on a per-literal basis instead of turning it on for every list literal within the module.</div>
</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 26, 2013 at 9:45 AM, Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>
<span class="HOEnZb"><font color="#888888">
<div><font face="courier new, monospace"><br></font></div><div>-Edward<br></div></font></span></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">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>
</div><div><div class="h5"><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>
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>
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></div></div><br></div>
<br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>