ndmitchell#372, add a FAQ entry in the README

Author: Damien Couroussé

README.md

@@ -175,18 +175,36 @@ Most hints are perfect substitutions, and these are displayed without any notes.
 
 * __Increases laziness__ - for example `foldl (&&) True` suggests `and` including this note. The new code will work on infinite lists, while the old code would not. Increasing laziness is usually a good idea.
 * __Decreases laziness__ - for example `(fst a, snd a)` suggests a including this note. On evaluation the new code will raise an error if a is an error, while the old code would produce a pair containing two error values. Only a small number of hints decrease laziness, and anyone relying on the laziness of the original code would be advised to include a comment.
-* __Removes error__ - for example `foldr1 (&&)` suggests and including the note `Removes error on []`. The new code will produce `True` on the empty list, while the old code would raise an error. Unless you are relying on the exception thrown by the empty list, this hint is safe - and if you do rely on the exception, you would be advised to add a comment. 
+* __Removes error__ - for example `foldr1 (&&)` suggests and including the note `Removes error on []`. The new code will produce `True` on the empty list, while the old code would raise an error. Unless you are relying on the exception thrown by the empty list, this hint is safe - and if you do rely on the exception, you would be advised to add a comment.
 
 ### What is the difference between error/warning/suggestion?
 
 Every hint has a severity level:
 
-* __Error__ - by default only used for parse errors. 
+* __Error__ - by default only used for parse errors.
 * __Warning__ - for example `concat (map f x)` suggests `concatMap f x` as a "warning" severity hint. From a style point of view, you should always replace a combination of `concat` and `map` with `concatMap`.
 * __Suggestion__ - for example `x !! 0` suggests `head x` as a "suggestion" severity hint. Typically `head` is a simpler way of expressing the first element of a list, especially if you are treating the list inductively. However, in the expression `f (x !! 4) (x !! 0) (x !! 7)`, replacing the middle argument with `head` makes it harder to follow the pattern, and is probably a bad idea. Suggestion hints are often worthwhile, but should not be applied blindly.
 
 The difference between warning and suggestion is one of personal taste, typically my personal taste. If you already have a well developed sense of Haskell style, you should ignore the difference. If you are a beginner Haskell programmer you may wish to focus on warning hints before suggestion hints.
 
+### Is it possible to use pragma annotations in code that is read by `ghci` (conflicts with `OverloadedStrings`)?
+
+Short answer: yes, it is!
+
+If the language extension `OverloadedStrings` is enabled, `ghci` may however report error messages such as:
+```
+Ambiguous type variable ‘t0’ arising from an annotation
+prevents the constraint ‘(Data.Data.Data t0)’ from being solved.
+```
+
+In this case, a solution is to add the `:: String` type annotation.  For example:
+
+```
+{-# ANN someFunc ("HLint: ignore Use fmap" :: String) #-}
+```
+
+See discussion in [issue #372](https://github.com/ndmitchell/hlint/issues/372).
+
 ## Customizing the hints
 
 To customize the hints given by HLint, create a file `.hlint.yaml` in the root of your project. For a suitable default run: