how does HIE depend on the GHC version?

[Thomas Koch]

Hi,

I'm trying to understand why hie depends on the GHC version that the project gets compiled with? I only found this comment:

"Hie is like ghci in that it actually loads the project, to get info. For

that to work, the GHC version built into hie must be able to load the 

compiled products."

https://github.com/haskell/haskell-ide-engine/issues/439#issuecomment-371416708

What are "the compiled products"? I suppose this are either the interface files (.hi) or object files (.o)?

https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/separate_compilation.html#output-files

Where exactly is the code that "loads the project"? Is it only one isolated place in hie that depends on the right GHC version match?

I thought I read somewhere that ghcid would solve this problem differently and thus does not need this exact version match, but I can't find this anymore.

Wouldn't it be an option if GHC would produce version independent files? What makes it hard to make those files version independent?

Sorry for the naive questions....

[Alan & Kim Zimmerman]

Thomas

Basically hie includes a version of the GHC compiler in it.  The project is compiled with a version of GHC, and to get errors/warnings in hie we compile the file being edited with the GHC in hie.  For this to work, it has to be able to load the other parts of the project, and all the libraries configured for the project (the dependencies specified in the cabal file).

I do not know how ghcid solves this problem, but I am pretty sure it involves keeping the GHC version used by ghcid in sync with the one in the project.

Alan

--
You received this message because you are subscribed to the Google Groups "Haskell IDE implementation discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-ide+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Gröber]

Hi,

On Sun, Jun 10, 2018 at 07:22:53AM -0700, Thomas Koch wrote:
> I'm trying to understand why hie depends on the GHC version that the
> project gets compiled with? I only found this comment:
>
> "Hie is like ghci in that it actually loads the project, to get info. For
> that to work, the GHC version built into hie must be able to load the 
> compiled products."
> https://github.com/haskell/haskell-ide-engine/issues/439#
> issuecomment-371416708
>
> What are "the compiled products"? I suppose this are either the interface
> files (.hi) or object files (.o)?
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/
> separate_compilation.html#output-files

That sort of what it means but you're missing the point. Say you have
a random Haskell project and you want to load it into GHCi. If this
project doesn't have any dependencies you can essentially just do:

$ ghci src/Foo.hs src/Bla/Bar.hs ...

and GHCi will go off and byte-compile those two modules. You don't
need any pre-existing compilation products to do this, GHCi will just
compile everything from scratch.

Now if you have a project that has package dependencies the situation
is different. You have to have the packages you want to use already
available in GHC's package-database or this will happen:

$ ghci -package somepackage src/Foo.hs src/Bar.hs
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
<command line>: cannot satisfy -package somepackage
(use -v for more information)

Ok, so you go off and install somepackage with `cabal`:

$ cabal install somepackage

now GHCi is happy and the command above will work.

The problem is cabal just compiled and installed 'somepackage' using
whatever GHC version was on PATH when you run it. So if we now switch
to a different GHC version we're back where we started:

$ /path/to/ghc-8.4/ghci -package somepackage src/Foo.hs src/Bar.hs
GHCi, version 8.4.1: http://www.haskell.org/ghc/ :? for help
<command line>: cannot satisfy -package somepackage
(use -v for more information)

because GHC's build output is just not compatible across compiler
versions like one might expect a C compiler's output to be. So each
GHC version has it's own set of installed packages.

This is the core "problem" though it's really just a fact of life with
GHC/Haskell. Essentially HIE ought to be treated as if it were part of
GHC, i.e. when you upgrade GHC you upgrade HIE then everything works
but it's just not that easy to do.

> Where exactly is the code that "loads the project"? Is it only one
> isolated place in hie that depends on the right GHC version match?

It is in one isolated place so to speak. In GHC. :)

> I thought I read somewhere that ghcid would solve this problem differently
> and thus does not need this exact version match, but I can't find this
> anymore.

GHCid does things rather differently, its just a fancy wrapper around
GHCi. Like it literally starts a GHCi process and then talks to it via
stdin/stdout. That's it. So it just doesn't have this problem.

> Wouldn't it be an option if GHC would produce version independent files?
> What makes it hard to make those files version independent?

GHC is a research compiler, requiring its build output to be forward
compatible would just slow down development. While this would be
possible in principle it would be a _lot_ of work and for what? Minor
convinience.

--Daniel