Use ghc-lib for GHC >= 8.8

[zliu41]

#93

GHC 9.0: supporting both ghc and ghc-lib
GHC 8.8, 8.10: supporting ghc-lib only
GHC <= 8.6: supporting ghc only

Removed src-ghc88 and src-ghc810. src-ghc90 is renamed to src-ghc88-810-90.
tests/examples/pre-ghc90 and tests/examples/pre-ghc810 are combined into tests/examples/pre-ghc88.

The compat code in Utils.hs used to implement ghcWrapper is borrowed (with modification) from here, originally written by @arybczak. Thanks @shayne-fletcher for the pointer.

[alanz]

Ping @xich, @lspitzner , @rayshih any comments?

[alanz]

I have reservations about this approach, primarily because I want to be able to use ghc-exactprint to drive refactorings based on compiler analysis of names, types, and so on.

As I understand it, using ghc-lib removes this, as it only does parsing.

[shayne-fletcher]

I have reservations about this approach, primarily because I want to be able to use ghc-exactprint to drive refactorings based on compiler analysis of names, types, and so on.

As I understand it, using ghc-lib removes this, as it only does parsing.

ghc-lib provides for phases up-to and including generation of core so that includes renaming & type-checking.

[xich]

@shayne-fletcher Can you elaborate on this limitation in the README?

While ghc-lib isn't tied to any specific GHC versions, it can only read package databases and .hi files for one particular version of GHC. That means your existing package database probably can't be consumed by ghc-lib (unless you happen to perfectly match the GHC version, in which case you could just have used the GHC API), and it doesn't ship with a package database so you'd have to painfully build your own.

I think this is the limitation that scares me. I want to be able to rename a module and get all the exact Names for things that come from other packages (e.g. Data.List.map). Will that be possible with ghc-lib?

[shayne-fletcher]

@shayne-fletcher Can you elaborate on this limitation in the README?

While ghc-lib isn't tied to any specific GHC versions, it can only read package databases and .hi files for one particular version of GHC. That means your existing package database probably can't be consumed by ghc-lib (unless you happen to perfectly match the GHC version, in which case you could just have used the GHC API), and it doesn't ship with a package database so you'd have to painfully build your own.

I think this is the limitation that scares me. I want to be able to rename a module and get all the exact Names for things that come from other packages (e.g. Data.List.map). Will that be possible with ghc-lib?

ah, ok. yes, i see what you mean. sadly, i think this is where we're we hit the limits of what is possible with ghc-lib 😞 .

[zliu41]

So there's no non-painful way to use ghc-lib to rename/typecheck a module that imports anything third-party, even base, I guess? That's not currently a problem, but yeah, if the long term plan is to make ghc-exactprint a full-fledged linting/refactoring tool with the ability to type check, then it would be a very different story.

Something worth considering is that not supporting ghc-lib makes depending on ghc-exactprint or its downstream packages (e.g. apply-refact) as libraries less convenient (e.g., this comment). So instead of adding more features, I'd suggest considering the option of putting new features in a separate package or even reducing features.

For example, if we remove CPP support from ghc-exactprint, we would no longer need to call preprocess, and so (I think) we wouldn't need to use the Ghc monad altogether, which happens to resolve #96. Most Haskell projects either don't use CPP or use it in only one or a few modules, so this shouldn't be a severe loss.

[alanz]

For example, if we remove CPP support from ghc-exactprint, we would no longer need to call preprocess,

I would be happy to accept a PR splitting ghc-exactprint into pieces, if it enables a simpler reuse/installation story.

[zliu41]

I would be happy to accept a PR splitting ghc-exactprint into pieces, if it enables a simpler reuse/installation story.

Sounds good! Another issue with this approach is that it lets ghc-lib read the package database of a potentially different ghc version (since preprocess needs rts), which is not great. Splitting preprocess out would also solve this problem. Anyway, I'm closing the pr. Thanks all for chiming in!