Making GHCi awesomer?

Christopher Done chrisdone at
Sat Oct 18 21:01:27 UTC 2014

On 18 October 2014 22:36, Herbert Valerio Riedel <hvriedel at> wrote:

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.
Right, so far my work on ghc-server has all been doable as far back as GHC

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.

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....
It hasn’t been too tedious to support old versions at least on ghc-server —
I went back as far as 7.2, but GHC 7.6 for example is very similar to 7.8
so kind of comes “for free”. Makes sense, really. One major version bump to
another is rather passable, it’s when going a few versions back that it
becomes tedious. At least in my experience. I’ll see anyway.

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...
Indeed, I was considering extracting and embedding a simple parser/printer
from the old json package (remember that?). Served me well for years before
aeson usurped it. :-) I think it can be reduced down to one module that
operators on Strings.

PS: I've added you to
>, just in
> case...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list