Go to file
Daniel Gröber c50b4f5a38 ghc-mod deserves it's own monad
Having to call `findCradle` and `initializeFlagsWithCradle` everywhere
we interact with ghc-mod's API doesn't seem very Haskell-like to me I
think we should provide a Monad that has a run function that already
does all those tedious tasks for us.

The `GhcMod` monad is basically a wrapper around `RWST r w s IO` with an
instance for `GhcMonad`

Having a `Reader` allows us to pass `Options` to runGhcMod and not have
to worry about passing it everywhere, `Cradle` is also stored in the
reader environment on initialization.

Writer and State are just there for future use.

I've included a `toGhcMod` function that turns a `Ghc a` into a `GhcMod
a` this will make it easy to transition everyting to using the `GhcMod`
monad instead of `Ghc` without breaking the build or test suite for
extended periods of time.

Conflicts:
	ghc-mod.cabal
2014-05-04 04:57:38 +02:00
Language/Haskell ghc-mod deserves it's own monad 2014-05-04 04:57:38 +02:00
elisp (discard-input) avoids getting stuck. 2014-04-28 21:27:27 +09:00
src bootInfo as API. 2014-04-30 10:49:25 +09:00
test Cabal needs empty 00-index.cache and 00-index.tar in sanxbox 2014-05-03 15:38:27 +02:00
test-elisp adding test cases for elisp. 2014-04-23 14:51:02 +09:00
.ghci .ghci for ghci-friendliness (testing) 2012-01-22 20:16:22 -08:00
.gitignore Add package.cache to .gitignore and make .cabal-sandbox absolute 2014-05-03 15:35:04 +02:00
.travis.yml Add `cabal` to PATH in travis script 2014-05-03 15:36:10 +02:00
ChangeLog changelog. 2014-04-30 21:45:39 +09:00
LICENSE adding README and LICENSE. 2010-03-10 12:13:03 +09:00
README.md README. 2014-04-26 09:18:36 +09:00
Setup.hs adding Setup.hs. 2010-04-03 00:16:22 +09:00
ghc-mod.cabal ghc-mod deserves it's own monad 2014-05-04 04:57:38 +02:00
hcar-ghc-mod.tex hcar. 2014-04-30 12:40:41 +09:00

README.md

Happy Haskell Programming

Build Status

Please read: http://www.mew.org/~kazu/proj/ghc-mod/

Latest ELisp front-end can also be installed via MELPA. The package name is "ghc". But it appeared that if you use MELPA, inconsistency between Emacs front-end and ghc-mod/ghc-modi happens. So, please use github directly.