How does `-XOverloadedStrings` work? (in Yesod) - string

Question

I'm following Yesod tutorials from their official yesod book. (http://www.yesodweb.com/book/basics)
Unfortunately their tutorials on the book won't work, worse is that its output is very cryptic message about types not mathcing that took me quite a while to understand. Here's their original code and error message which is produced by the code:
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE QuasiQuotes #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeFamilies #-}
import Yesod
data Links = Links
mkYesod "Links" [parseRoutes|
/ HomeR GET
|]
instance Yesod Links
getHomeR = return $ object ["msg" .= "Hello World"]
main :: IO ()
main = warp 3000 Links
error:
helloworld2.hs:18:36:
No instance for (ToJSON a0) arising from a use of ‘.=’
The type variable ‘a0’ is ambiguous
Note: there are several potential instances:
instance ToJSON a => ToJSON (Control.Applicative.Const a b)
-- Defined in ‘Data.Aeson.Compat’
instance ToJSON (Data.Proxy.Proxy a)
-- Defined in ‘Data.Aeson.Compat’
instance ToJSON Data.Version.Version
-- Defined in ‘Data.Aeson.Compat’
...plus 7 others
In the expression: "msg" .= "Hello World"
In the first argument of ‘object’, namely
‘["msg" .= "Hello World"]’
In the second argument of ‘($)’, namely
‘object ["msg" .= "Hello World"]’
helloworld2.hs:18:40:
No instance for (Data.String.IsString a0)
arising from the literal ‘"Hello World"’
The type variable ‘a0’ is ambiguous
Note: there are several potential instances:
instance Data.String.IsString Value
-- Defined in ‘aeson-0.9.0.1:Data.Aeson.Types.Internal’
instance (a ~ Data.ByteString.Internal.ByteString) =>
Data.String.IsString
(attoparsec-0.13.0.1:Data.Attoparsec.ByteString.Internal.Parser a)
-- Defined in ‘Data.Attoparsec.ByteString.Char8’
instance (a ~ Data.Text.Internal.Text) =>
Data.String.IsString
(attoparsec-0.13.0.1:Data.Attoparsec.Text.Internal.Parser a)
-- Defined in ‘attoparsec-0.13.0.1:Data.Attoparsec.Text.Internal’
...plus 9 others
In the second argument of ‘(.=)’, namely ‘"Hello World"’
In the expression: "msg" .= "Hello World"
In the first argument of ‘object’, namely
‘["msg" .= "Hello World"]’
it seems object ["msg" .= "Hello World"] is the problem. GHC doesn't understand what are types of "msg" and "Hello World", and can't build a JSON object out of them. I had to make their types explicit, that:
import Data.Text (Text)
getHomeR = return $ object [("msg" :: Text) .= ("Hello World" :: Text)]
it seems Aeson has toJSON instances for Text type, and I've heard that most of the text-processing codes use Text type, not String ([Char]) for efficiency reasons. But wouldn't it be nice, if every double-quoted code ("msg", "Hello World") is parsed as Text instead of String automatically? I've thought the OverloadedStrings pragma tells the compiler to do exactly that("overload" the strings into Text), but above errors without type signature indicates that I was wrong.
of course, If I have to give :: Text type signature for every string I write for output it would be very tedious and cumbersome - is there any solution for this, or is it me just don't understand enough to write Haskell and Yesod codes?

Answer 1

When you use OverloadedStrings, explicit strings are treated in a similar way to explicit numbers. So
x = "foo"
is desugared into
x = fromString "foo"
The IsString class defines the "fromString" function, so now all the type checker knows is that
x :: (IsString a) => a
So this is why the compiler is complaining that the type is ambiguous. There are several different string types with a ToJSON instance, and the compiler is complaining that it doesn't know which one to pick.
The only solutions, I'm afraid, are to lose the OverloadedStrings or to put in explicit type annotations to tell the compiler which instance to pick.
On String versus Text: efficiency is not a particularly big issue when you are using short constant strings like this. If you are processing text in bulk then its a bigger issue, and also the Haskell concept of String = [Char] breaks down in some languages. Text handles these properly, but String doesn't. So if you ever need to internationalise your code then String can present you with obscure problems when you try to do things like capitalise words.

Answer 2

The JSON code snippet you're looking at does work correctly straight out of the book. There's an additional pragma at the top of it that's missing from your code:
{-# LANGUAGE ExtendedDefaultRules #-}
I'm not a huge fan of the code snippet doing that, since I'm pretty sure people don't use that pragma in production code. It would be more typical to write the code like this:
getHomeR = return $ object ["msg" .= ("Hello World" :: String)]
Note that GHCi uses ExtendedDefaultRules to make it easier to enter expressions into the REPL without having to specify their type. If you type object ["msg" .= "Hello World"] into GHCi it'll tell you what it's defaulting to:
ghci > object ["msg" .= "Hello World"]
<interactive>:2:18: Warning:
Defaulting the following constraint(s) to type ‘String’
(IsString a0)
arising from the literal ‘"Hello World"’ at <interactive>:2:18-30
(ToJSON a0) arising from a use of ‘.=’ at <interactive>:2:15-16
In the second argument of ‘(.=)’, namely ‘"Hello World"’
In the expression: "msg" .= "Hello World"
In the first argument of ‘object’, namely
‘["msg" .= "Hello World"]’
<interactive>:2:18: Warning:
Defaulting the following constraint(s) to type ‘String’
(IsString a0)
arising from the literal ‘"Hello World"’ at <interactive>:2:18-30
(ToJSON a0) arising from a use of ‘.=’ at <interactive>:2:15-16
In the second argument of ‘(.=)’, namely ‘"Hello World"’
In the expression: "msg" .= "Hello World"
In the first argument of ‘object’, namely
‘["msg" .= "Hello World"]’
Object (fromList [("msg",String "Hello World")])

Answer 3

object takes a list of Pair values as argument. Pair is type Pair = (Text, Value) and it is an instance of tye KeyValue typeclass, which provides the convenience constructor (.=) :: ToJSON v => Text -> v -> kv.
The problem is as follows: .= requires the value type to have a ToJSON instance, but doesn't force the caller into any concrete type.
Meanwhile, the fromString function from IsString is overloaded on its return type: fromString :: String -> a. The precise implementation to call is determined from the return type. When OverloadedStrings is used, fromString is called implicitly for string literals.
If we feed directly the result of fromString as the value argument of .=, the compiler doesn't have enough information to assing a concrete type to the value. Should it create a Text value and convert it to json? Or perhaps create a ByteString instead and convert it to json? The problem is similar to ambiguous compositions like show . read.
Personally, instead of using type annotations I would solve the ambiguity by wrapping the string literals using the String constructor of the Value type. It tells the compiler that the literal will be Text, and of course Value is an instance of ToJSON. This is a bit less verbose than type annotations:
foo :: Value
foo = object ["foo" .= String "faa"]
You could also define a specialization of .= that took a concrete Text as the value:
(.=|) :: KeyValue kv => Text -> Text -> kv
(.=|) = (.=)
foo :: Value
foo = object ["foo" .=| "faa"]