
On Sun, Sep 23, 2012 at 5:51 PM, Chris Smith
Michael Snoyman
wrote: That said, it would be great to come up with ways to mitigate the downsides of unbounded polymorphism that you bring up. One idea I've seen mentioned before is to modify these extension so that they target a specific instance of IsString/IsList, e.g.:
{-# STRING_LITERALS_AS Text #-}
"foo" ==> (fromString "foo" :: Text)
That makes sense for OverloadedStrings, but probably not for OverloadedLists or overloaded numbers... String literals have the benefit that there's one type that you probably always really meant. The cases where you really wanted [Char] or ByteString are rare. On the other hand, there really is no sensible "I always want this" answer for lists or numbers. It seems like a kludge to do it per-module if each module is going to give different answers most of the time.
-- Chris
Note that I wasn't necessarily advocating such a pragma. And a lot of my XML code actually *does* use two IsString instances at the same time, e.g.: Element ("img" :: Name) (singleton ("href" :: Name) ("foo.png" :: Text)) [NodeComment ("No content inside an image" :: Text)] (Courtesy of xml-conduit.) To prove your point even further, with OverloadedLists we could replace that `singleton` call with `[("href", "foo.png")]` and then be using two `IsList` instances simultaneously as well (`Map` and `[]`). Also, I use the `ByteString` instance of `IsString` regularly when using `http-conduit` and `warp` (for all of the header values), and to an even greater extent when hacking on the internals of any HTTP library (whether `http-conduit` or something in the `wai` ecosystem). Michael