On 2014-10-18 at 19:59:24 +0200, Christopher Done wrote: [...]
Herbert doesn't have time to hack on it, but was encouraging about continuing with ghci-ng.
Yeah, it's quite convenient to hack on GHCi that way as it's just an ordinary Cabal package (so it doesn't require to setup a GHC source-tree and wrangle with the GHC build-system), if you're lucky enough (which is most of the time) that the parts you want to tweak don't require changing the GHC API.
I'm thinking to try forward-porting ghci-ng to GHC 7.8,
Iirc all of the deltas in ghci-ng-7.6 relative to GHC 7.6.3 landed in GHC 7.8.1, so extracting the latest GHCi frontend code would be probably better.
or otherwise extracting GHC 7.8's GHCi again and then backporting it to 7.6.
Fwiw, I setup the ghci-ng .cabal's in such a way, that if you 'cabal install ghci-ng' with a GHC 7.4.x, you'd get a ghci-ng-7.4.2.1, while when on GHC 7.6.x, ghci-ng-7.6.3.5 would be selected. Supporting multiple major-versions of the GHC API simultanously in the same code-base could prove to be rather tedious (and make it more difficult to extract clean patches to merge back into GHC HEAD). But this is only speculation on my part, so your mileage may vary....
(Under the assumption that current + past is a reasonable number of GHCs to support.) I'm going to experiment with the JSON interface and I'll report back with results.
You may want to be careful with the build-deps though; e.g. if you use JSON and want this to be merged back into GHC HEAD at some point, we may need something lighter than the usual go-to JSON implementation `aeson` in terms of build-deps... PS: I've added you to http://hackage.haskell.org/package/ghci-ng/maintainers/, just in case...