Add README text about all the language extensions needed and about using cabal-dev instead.

The cabal file keeps track of the options necessary to install the package successfully. Running cabal-dev ghci will automatically take the cabal file options into account when launching ghci. Therefore, it is probably preferable to maintaining your own .ghci file.

README.md

@@ -99,10 +99,11 @@ cabal configure
 cabal build
 ```
 
-Loading IHaskell into GHCi for testing:
+**Loading IHaskell into GHCi for testing:**
+
 If you want to play around with IHaskell by loading it into GHCi, you need to include the ghc package and the cabal macros file. cabal_macros.h is generated by the ```cabal build``` command and the file is placed in the build directory. You will also need to use the OverloadedStrings language extension. So if you are at the top level of the IHaskell project, you can load GHCi as follows: 
 ```bash
-ghci -XOverloadedStrings -package ghc -optP-include -optPdist/build/autogen/cabal_macros.h
+ghci -XDoAndIfThenElse -XNoImplicitPrelude -XOverloadedStrings -package ghc -optP-include -optPdist/build/autogen/cabal_macros.h
 ```
 
 or you can create a .ghci file in the top level directory, like so: 
@@ -113,6 +114,17 @@ or you can create a .ghci file in the top level directory, like so:
 :set -package ghc
 :set -package ghc-paths
 :set -optP-include -optPdist/build/autogen/cabal_macros.h
-:set -XOverloadedStrings
+:set -XDoAndIfThenElse -XNoImplicitPrelude -XOverloadedStrings
+
+```
+
+**Using cabal-dev instead:**
+
+Another option is to use [cabal-dev](https://github.com/creswick/cabal-dev/blob/master/README.md) instead of cabal. This creates a sandboxed environment within the project directory. This avoids dependency conflicts. But it does take a little while to download and install all the dependencies. You can also use cabal-dev to call ghci with all the cabal options automatically imported. 
+
+```bash
+cd <path-to-IHaskell>
+cabal-dev install
+cabal-dev ghci
 ```