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.
