<div dir="ltr"><div><div><div>Thanks for kicking off this thread Alan. I'm 100% behind the idea of working on unified tooling, and am happy to participate in making that happen.<br><br></div>JP: You're right to bring up ide-backend. Let's start a real discussion (as part of what Alan's kicked off here) about what the best future for these projects would be. I don't want to predetermine the outcome of that conversation now, but I can say that anything up to merging ide-backend into ghc-mod and deprecating ide-backend as a separate project would be acceptable to me. Whatever makes the most sense for improved community tooling is what we should do.<br><br></div>As for stack-ide, we already have slowed down development on it as a result of the changes to ghc-mod recently. None of us on the project had a chance yet to really analyze the situation and sync up with the ghc-mod team yet (mostly due to some travel), but at least IMO the ideal will be a single tool that supports multiple project structures (cabal, cabal sandbox, stack, etc) and various editor frontends.<br><br></div>I don't have much structured thought right now on what the end game of all of this should look like, but I'll be happy to be part of the conversation and help get us to that better tooling future.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 14, 2015 at 11:19 AM, JP Moresmau <span dir="ltr"><<a href="mailto:jpmoresmau@gmail.com" target="_blank">jpmoresmau@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">ide-backend (<a href="https://github.com/fpco/ide-backend" target="_blank">https://github.com/fpco/ide-backend</a>) provides a JSON layer (<a href="https://github.com/commercialhaskell/stack-ide" target="_blank">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"><div><div class="h5">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></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><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></div></div>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">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><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>JP Moresmau<br><a href="http://jpmoresmau.blogspot.com/" target="_blank">http://jpmoresmau.blogspot.com/</a></div>
</font></span></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></div>