Making GHCi awesomer?

[Herbert Valerio Riedel]

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...