From: Christopher Done
1. The first problem with this is that every three projects will segfault or panic when trying to load in a project that GHCi will load in happily. [...] People have similar complaints of GHC Mod & co. “Getting it to work” is a deterrant.
Do you have any examples of such projects, I've never seen any complaints about ghc-mod doing this.
So, of course, this got me thinking that I could instead make ghc-server be based off of GHCi’s actual codebase. I could rebase upon the latest GHC release and maintain 2-3 GHC versions backwards. That’s certainly doable, it would essentially give me “GHCi++”. Good for me, I just piggy back on the GHCi goodness and then use the GHC API for additional things as I’m doing now.
I had that idea too for ghc-mod unfortunately it's not so easy as ghci's internal API mostly consists of functions that only have side effects (i.e. don't return anything you can process further) :/
But is there a way I can get any of this into the official repo? For example, could I hack on this (perhaps with Herbert) as “ghci-ng”, provide an alternative JSON communication layer (e.g. via some ―use-json flag) and and socket listener (―listen-on ), a way to distinguish stdout/stderr (possibly by forking a process, unsure at this stage), and then any of the above features (point 4) listed. I make sure that I’m rebasing upon HEAD, as if to say ghci-ng is a kind of submodule, and then when release time comes we merge back in any new stuff since the last release. Early adopters can use ghci-ng, and everyone benefits from official GHC releases.
The only snag there is that, personally speaking, it would be better if ghci-ng would compile on older GHC versions. So if GHC 7.10 is the latest release, it would still be nice (and it *seems* pretty feasible) that GHC 7.8 users could still cabal install it without issue. People shouldn’t have to wait if they don’t have to.
Sounds awesome I'd love to get in on this :) --Daniel