RFC: Add ghc-modi syntax plugin for haskell

[wuzzeb]

ghc-modi is a version of ghc-mod which caches data between runs, improving the time to check for errors to under half a second, even for large projects.

This is still more of an RFC, because I am not sure if this should go as a new checker or if I should merge the code directly into ghc-mod plugin. Also, is the change to SyntasticMake ok? Lastly, I still need to add a command to kill the ghc-modi instance.

[lcd047]

ghc-modi is a version of ghc-mod which caches data between runs

As I understand it, it doesn't cache data between runs. Rather, it's a server that can be used (among other things) to check Haskell files. It keeps data from previous checks in memory until it exits, but as far as I can tell it doesn't actually cache anything between (server) runs.

This is still more of an RFC, because I am not sure if this should go as a new checker or if I should merge the code directly into ghc-mod plugin.

Neither. Perhaps you should maintain this as an external checker.

Also, is the change to SyntasticMake ok?

(edited, after some pondering)

It isn't. Your patch, as it is, tries to do to either much, or too little. The client-server model for checkers is an interesting concept, but syntastic doesn't support that, at least not yet. Your patch adds a global external dependency to Shougo's vimproc to handle it, and it bypasses SyntasticMake() to get away with it. This is wrong on many levels. Right now syntastic doesn't have any global external dependencies. Depending on vimproc would have been fine if either (1) your patch added a general framework for client-server checkers, or (2) your checker did its job without touching the surrounding code. Either way, your patch should have checked that vimproc is actually installed.

Inventing a new way to talk to external checkers besides system() could be useful, but plumbing it to bypass SyntasticMake() is bad design. Perhaps using an external Python daemon along the lines of powerline-daemon might be worth a try. Or perhaps one of the other async mechanisms mentioned in #699 could be used. There are some potentially interesting applications there, if you go beyond the scope of a single checker.

[wuzzeb]

I updated the code to not use SyntasticMake at all so no changes to syntastic itself needed

wuzzeb@69be740

• Using any async stuff doesn't make any sense. Even if syntastic supported async commands I wouldn't use it. The checker runs under a second so running it sync is perfect. All async would do is complicate the code for no benefit.
• I thought briefly about enhancing the syntastic internals for this type of checker, but couldn't come up with a good API. There is quite a bit of details w.r.t. multiple servers for different sandbox roots that I can't see any syntastic functions helping that much.
• I also thought about using python, but even the simplest python program would be 50+ lines of code since you need to manage the servers, make sure they don't become zombies, deal with the network or socket communication, etc. Compare that with essentially 3 vimproc calls, using vimproc is much simpler.

[lcd047]

I updated the code to not use SyntasticMake at all so no changes to syntastic itself needed

That's great: it makes it easier for you to maintain it as an external checker.

[int3]

@wuzzeb -- any interest in maintaining it as an external checker? I copied the file from your repo and it works great :) But having it as part of Vundle's automatic update process would be even more awesome. I'm sure other Haskellers would appreciate it, too.

[sdx23]

@wuzzeb having this as an external checker would be really nice. Would you do this? Otherwise, if you don't mind I'll provide (and maintain) this, especially since it also fixes #1576