<div dir="ltr">literally just for sharing the code for that parsing afaik.<div>I think theres a ticket for doing this.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 11, 2014 at 2:48 PM, Bardur Arantsson <span dir="ltr"><<a href="mailto:spam@scientician.net" target="_blank">spam@scientician.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 2014-03-11 09:20, JP Moresmau wrote:<br>
> Unifying all the different tools underlying IDEs has been talked again<br>
> before, because the pain is real. For example, see<br>
> <a href="https://github.com/fpco/haskell-ide/wiki" target="_blank">https://github.com/fpco/haskell-ide/wiki</a>. I've written about the GHC API in<br>
> that wiki, and some of the issues that it has for such tools.<br>
> Currently EclipseFP uses buildwrapper, which is a backend I wrote because I<br>
> was dissatisfied with scion. It integrates the GHC API and Cabal, so that<br>
> it aims to give the same results that running cabal configure/build. It<br>
> usually run as a shortlived executable but for performance reason it is<br>
> possible to have a long lived session to avoid reloading the modules in GHC<br>
> all the times.<br>
> Yes, GHC depends on the Cabal API for some types, which causes untold woes<br>
> when you use buildwrapper after upgrading Cabal, for example. There is a<br>
> bug report to remove that dependency but I had no time yet to work on it,<br>
> so far I've used dynamic-cabal in buildwrapper to allow a newer version of<br>
> Cabal, at the price of more complexity. But a complete tool would need to<br>
> integrate both, so it can't be ghci only, otherwise Cabal and GHC would<br>
> become really stuck together.<br>
> The GHC API uses some global settings, which means you sometimes have no<br>
> choice (if stcouldatic flags change) than to respawn a new process. This<br>
> could probably be improved since it's not really the way a well behaved<br>
> Haskell program should act. Memory usage is also a concern.<br>
><br>
> So I think there should be two lines of work here: one would be to improve<br>
> the GHC API and/or the ghci interface, to make it more IDE friendly, the<br>
> other would be to unify all these tools like scion/buildwrapper/ghc-mod in<br>
> one tool that would hopefully provide all services an IDE needs, and that<br>
> would allow easy plugin of additional functionality (so for example HaRe<br>
> could easily add its refactoring capabilities to it). I would happily<br>
> switch from buildwrapper to another community supported tool if all the<br>
> functionality I currently have is kept in one form or another.<br>
><br>
<br>
</div></div>Since you've obviously been doing a lot of investigation here, I thought<br>
I might ask:<br>
<br>
What is GHC using Cabal for in *functional terms*, i.e. what actual<br>
functionality is it using? Is it just parsing package information files?<br>
What is it using that information for? Would it be possible to supply<br>
that information via other mechanisms than GHC snooping in the files?<br>
I'm thinking something along the lines of pkg-config here.<br>
<br>
(I understand the build system is a different issue, let's just ignore<br>
that completely.)<br>
<br>
Regards,<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>