If Ian can make defaulting work, then I'd prefer that solution. It hurts nobody and just makes everything work better. length was just the most galling example among many. 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. There are a lot of desiderata to consider in balancing the needs of base. 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. 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 OverloadedStrings. Forcing users to use signatures on every String and import Data.Traversableand Data.Foldable qualified "works," but it is the design equivalent of sticking your head in the sand and pretending their we don't have any problems. -Edward On Mon, Aug 26, 2013 at 12:33 PM, Henning Thielemann < schlepptop@henning-thielemann.de> wrote:
Am 25.08.2013 23:02, schrieb Edward Kmett:
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.
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.
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.
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".
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).
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?