[Haskell-cafe] On Haskell IDEs

[Bardur Arantsson]

On 2014-03-11 09:20, JP Moresmau wrote:
> Unifying all the different tools underlying IDEs has been talked again
> before, because the pain is real. For example, see
> https://github.com/fpco/haskell-ide/wiki. I've written about the GHC API in
> that wiki, and some of the issues that it has for such tools.
> Currently EclipseFP uses buildwrapper, which is a backend I wrote because I
> was dissatisfied with scion. It integrates the GHC API and Cabal, so that
> it aims to give the same results that running cabal configure/build. It
> usually run as a shortlived executable but for performance reason it is
> possible to have a long lived session to avoid reloading the modules in GHC
> all the times.
> Yes, GHC depends on the Cabal API for some types, which causes untold woes
> when you use buildwrapper after upgrading Cabal, for example. There is a
> bug report to remove that dependency but I had no time yet to work on it,
> so far I've used dynamic-cabal in buildwrapper to allow a newer version of
> Cabal, at the price of more complexity. But a complete tool would need to
> integrate both, so it can't be ghci only, otherwise Cabal and GHC would
> become really stuck together.
> The GHC API uses some global settings, which means you sometimes have no
> choice (if stcouldatic flags change) than to respawn a new process. This
> could probably be improved since it's not really the way a well behaved
> Haskell program should act. Memory usage is also a concern.
> 
> So I think there should be two lines of work here: one would be to improve
> the GHC API and/or the ghci interface, to make it more IDE friendly, the
> other would be to unify all these tools like scion/buildwrapper/ghc-mod in
> one tool that would hopefully provide all services an IDE needs, and that
> would allow easy plugin of additional functionality (so for example HaRe
> could easily add its refactoring capabilities to it). I would happily
> switch from buildwrapper to another community supported tool if all the
> functionality I currently have is kept in one form or another.
> 

Since you've obviously been doing a lot of investigation here, I thought
I might ask:

What is GHC using Cabal for in *functional terms*, i.e. what actual
functionality is it using? Is it just parsing package information files?
What is it using that information for? Would it be possible to supply
that information via other mechanisms than GHC snooping in the files?
I'm thinking something along the lines of pkg-config here.

(I understand the build system is a different issue, let's just ignore
that completely.)

Regards,