c50b4f5a38
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 |
||
---|---|---|
elisp | ||
Language/Haskell | ||
src | ||
test | ||
test-elisp | ||
.ghci | ||
.gitignore | ||
.travis.yml | ||
ChangeLog | ||
ghc-mod.cabal | ||
hcar-ghc-mod.tex | ||
LICENSE | ||
README.md | ||
Setup.hs |
Happy Haskell Programming
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.