Changing the defaulting, if that is possible, would be my preference - this way one can still use OverloadedString for list types. Disallowing them to allow for the default case to work doesn't seem quite right, though I guess it is acceptable if defaulting turns out to be impossible.


On Mon, Aug 26, 2013 at 1:24 AM, Edward Kmett <ekmett@gmail.com> wrote:
If that can be done in such a way that defaulting fires for FromString (say, even without EDR turned on) it could ensure OverloadedStrings has nearly zero impact on users.

This may not be an issue but you may need to check that just adding FromString to the list of classes for which defaulting is done is sufficient to make cases like (length "hello") work as unlike the other defaulting cases, you get situations where it is partially known. e.g. we've determined that the argument is [a], but not String. This can't happen with the Int, Integer, (), cases, which either unify or don't.

If you're looking at hacking up that part of the compiler, http://ghc.haskell.org/trac/ghc/ticket/8171 would also be really nice to clean up at the same time. ;)

-Edward


On Sun, Aug 25, 2013 at 6:16 PM, Ian Lynagh <igloo@earth.li> wrote:
On Sun, Aug 25, 2013 at 05:02:10PM -0400, Edward Kmett wrote:
>
> 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.

Would/could this be better addressed by changing
ghci/ExtendedDefaultRules such that the ambiguous uses would be
defaulted to String?


Thanks
Ian


_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries