<div dir="ltr">ide-backend (<a href="https://github.com/fpco/ide-backend">https://github.com/fpco/ide-backend</a>) provides a JSON layer (<a href="https://github.com/commercialhaskell/stack-ide">https://github.com/commercialhaskell/stack-ide</a>). I haven't tried it, since it requires stack and it's asking me to install the latest GHC 7.10.2 (sorry, I just wanted to have a look at the API, not reinstall a complete Haskell stack again), but maybe there are some good ideas there.<div>But before talking about API, shouldn't we talk about why we have ghc-mod and ide-backend? Can we merge them, or be clear what are their differences and when/why we should use one and not the other? We don't have fragmentation at the compiler level itself (with the dominance of GHC) but we seem to have some at the "nicer API on top of GHC" level. </div><div>Or maybe, should we have something in GHC itself, something like a GHC service that we could talk to via JSON or something, without having to use the complex, changing with each release GHC API, and have that part of GHC instead of having another tool to install?</div><div><br></div><div>My 2 cents,</div><div><br></div><div>JP</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 13, 2015 at 9:55 PM, Alan & Kim Zimmerman <span dir="ltr"><<a href="mailto:alan.zimm@gmail.com" target="_blank">alan.zimm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div>Historically ghc-mod provided (and still does) support for emacs and vim as part of its distribution.<br><br>It is also used by a number of other IDE backends to provide a way of getting information about a project without worrying
 too much about the details of how the project is organised on the file 
system.<br></div><br></div>There is currently a discussion between various interested parties about adjusting the way ghc-mod communicates with the IDE, to make it simpler to provide this support for other environments.<br><br></div>This should end up with a definition of a protocol that ghc-mod can expose, which should also allow tools (such as HaRe) to be plugged into it, so that IDE integration can be handled by the various IDE integrators in a clean, common way.<br><br></div>This is all just hand waving at the moment, so if anyone would like to get involved I am proposing that we revive the "Haskell IDE implementation"[1] google group/mailing list to host the discussion.<br><br></div>The new design is/will be captured here [2]<br><br></div>Regards<br></div>  Alan<br><br>[1] <a href="https://groups.google.com/forum/#!forum/haskell-ide" target="_blank">https://groups.google.com/forum/#!forum/haskell-ide</a><br>[2] <a href="https://github.com/kazu-yamamoto/ghc-mod/wiki/Library-API-Redesign" target="_blank">https://github.com/kazu-yamamoto/ghc-mod/wiki/Library-API-Redesign</a><br></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">JP Moresmau<br><a href="http://jpmoresmau.blogspot.com/" target="_blank">http://jpmoresmau.blogspot.com/</a></div>
</div>