Rethink/rework the HIE BIOS

[alanz]

haskell-ide-engine has the concept of a BIOS. which is the layer that interfaces with the underlying operating system, package manager, etc.

To date, we have been using modified versions of cabal-helper and ghc-mod, in forked repos from the main upstream.

It has now been several years, and we still cannot put hie onto hackage, because we do not have a clean dependency list.

So, time to reconsider our options.

• Apply resources to getting cabal-helper, ghc-mod-core and ghc-mod as used by hie onto hackage.

• Adapt https://github.com/kazu-yamamoto/hhp, which has cabal new-build support.

• Something else, perhaps based on what ghcid is doing.

Prerequisites are that it supports stack, cabal old build, cabal new-build, and nix.
But, realistically, we can assume GHC >= 8.2.2, and for the cabal builds, cabal-install >= 2.4.1.0

[alanz]

See also https://ghc.haskell.org/trac/ghc/ticket/15461

[Avi-D-coder]

How do the .hie files affect this? Will ghc-mod still be needed?

[alanz]

@Avi-D-coder The .hie files are unrelated. This is about being able to load a module under development, so that we can get information out of it.

This also includes managed a partly-edited but unsaved file.

[lorenzo]

What would be your preferred solution @alanz ?

[alanz]

@lorenzo I would rather keep an open mind at this stage, tbh.

[lukel97]

What exactly would the first option (getting cabal-helper/ghc-mod onto Hackage) involve? Would it be the case that we would have the HIE forks as a separate package on Hackage a-la cabal-helper-hie ghc-mod-hie?

[alanz]

@bubba Ideally it would involve getting them to a point where @DanielG would merge the changes and publish.

But I am concerned about his available time for this.

[shmish111]

I am very interested in this issue as I have been unable to get ghc-mod working on my OSX laptop (or a windows laptop previously) and I have tried many times over the last 3 years, including using nix.

Have you looked at https://github.com/google/haskell-indexer I doubt is has everything that is needed but it should provide a strong foundation for all the features that require static analysis. Additionally it doesn't load the whole index into memory and it is designed to be able to work with very large projects, something I feel ghc-mod or any tool that creates an in-memory index would struggle with.

And finally, I would really like to get this to work with https://github.com/tweag/rules_haskell so it would be great if HIE didn't require cabal, rather cabal and stack features should be optional, as would features for Bazel or Shake or any other build system.

[alanz]

it would be great if HIE didn't require cabal, rather cabal and stack features should be optional, as would features for Bazel or Shake or any other build system.

That is an interesting split point, and probably makes sense, given that in hie we basically want to know the shape of a project, and then load files as needed into GHC, regardless of how the specific config came about.

And I understand this is one of the great strengths of ghcid, it basically piggy-backs on ghci, so can work in any context where it is possible to start it up.

[eskimor]

I think making use of ghci together with this https://ghc.haskell.org/trac/ghc/ticket/15461 would improve/simplify things a lot! Also this would probably open the possibility for an obelisk project for example to re-use the ghci session ob run is using for hie, so I don't need to tell hie how to spawn a proper ghci session for my project and I don't end up having two ghci sessions running, which at best are wasting resources and worst might even interfere with each other.

[lorenzo]

@alanz would it be feasible to propose https://ghc.haskell.org/trac/ghc/ticket/15461 as a summer of code project? Sounds like it could be really handy for us

[mpickering]

I have a plan which will allow implementing HIE support for bazel, obelisk etc.

@shmish111 @eskimor Can you provide me some simple sample projects which I can use to test my implementation? (Nix compatible instructions preferable)