Split between haskell-ide-engine and haskell-plugin-api

[alanz]

The original idea was to keep hie-plugin-apilightweight, as just types, so that different projects could expose a PluginDescriptor as part of their normal publishing to hackage.

But it looks like hie-plugin-api is going to grow quite big, as we start putting utility stuff into it, in which case we may as well push the monad definition into it. Or at least the type for it.

This means that anything exposing a plugin will need ghc-mod, ghc and various other packages.

It also simplifies

type SyncCommandFunc resp = forall m. (MonadIO m,GHC.GhcMonad m,HasIdeState m)
                => [AcceptedContext] -> IdeRequest -> m (IdeResponse resp)

type AsyncCommandFunc resp = forall m. (MonadIO m,GHC.GhcMonad m,HasIdeState m)
                => (IdeResponse resp -> IO ()) -> [AcceptedContext] -> IdeRequest -> m ()

to

type SyncCommandFunc resp =  [AcceptedContext] -> IdeRequest -> IdeM (IdeResponse resp)

type AsyncCommandFunc resp = (IdeResponse resp -> IO ())
                          -> [AcceptedContext] -> IdeRequest -> IdeM ()

[alanz]

See also #112 (comment)

We need to make sure we can run in a multi-thread environment. Although this is already catered for in that the AsyncCommandFunc deliver response callback function is (IdeResponse resp -> IO ()), which is in IO.

[mgsloan]

I'm certainly in favor of putting lots of utilities into hie-plugin-api. It makes sense to put anything commonly needed by hie plugins into it.

This means that anything exposing a plugin will need ghc-mod, ghc and various other packages.

This seems quite reasonable to me.

There will likely be users of hie-plugin-api which don't provide a plugin, though. For example, if you have a client written in GHCJS, it makes sense to use the existing protocol types. How about splitting these types into a hie-protocol package which does not depend on ghc-mod / ghc? Not an urgent thing, but may as well do the move sooner rather than later.

[rvion]

I don't really know if a strong decision has been taken about ghc-mod being the root of hie, but from experience, ghcmodi is really slow compared to other deprecated or less used alternatives like ide-backend, or hdevtools.

(This comment may be irrelevant because I don't really know what ghc-mod is really used for in that case)

[mgsloan]

I haven't tried using ghc-modi, but based on the code, it's likely slow because it reparses / typechecks the target module every time you make a query (at least, for type info). It's possible that it's also slow due to the session caching bugs that need to get fixed, in this case, it'd be just as slow as normal ghc-mod).

Instead of doing this recompilation, ide-backend stores away the info needed to respond to queries during compilation. This has a cost of some time and memory during compilation, but makes queries very fast.