Major steps required (Roadmap)

[alanz]

• Plugins
• Implicit Configuration
• Multi-component / package (alpha, based on @mpickering work in progress)
• stack hie-bios flag
• cabal hie-bios flag
• Terminal modules (module graph)
• memory usage

2020-09-29 Update (@jneira)

• Plugins
• Implicit Configuration
• Multi-component / package (alpha, based on @mpickering work in progress)
• Ghcide master ghcide master? #173
• Module graph, implemented in @wz1000 hiedb branch of ghcide, There is a pr in ghcide to merge it: Integrate hiedb ghcide#898. The pr has been moved to hls: References via hiedb #704
• Change plugin architecture Project architecture to support plugins #164, Split HLS plugins into internal libraries #421
• Document global architecture Document architecture and relationship between component projects #409
• stack/cabal hie-bios flag: upstream changes in cabal/stack to make them give precise build info to hie-bios
  • cabal @fendor/@bubba show-build-info: Implement show-build-info for cabal-install cabal#7478
  • stack @chrisdone branch https://github.com/commercialhaskell/stack/compare/add-stack-ide-bios-cmd
  • main issue in hie-bios about: Proposal: better multi component support (including show-build-info) hie-bios#269 (comment)
• memory usage System hangs and crashes after consuming all 32GB of RAM #286, Leaking 10GB memory per minute with wrong type alias def type Foo = Foo for some ghc versions #352 and Space Leak #386 (and Memory usage #802 from ghcide)

[lukel97]

stack hie bios
https://gist.github.com/chrisdone/7ef391e8445216f5e30b2665b85a6db2

[jneira]

Have you considered use precompiled executables to use plugins at runtime, instead compile at runtime them? I guess they should be executed as daemons (like the ide server itself), to avoid the start process overhead.
We could use a subset (?) of lsp json format to comunicate between the ide main server and the plugin executables, to no reinvent any wheel.
This way the plugins+lsp could be even used in a isolated way from a vscode extension. In fact maybe we could distribute them as separate vscode extensions, keeping in the server only the core interface with ghc: compile errors, goto def, etc

Caveats: we had to wrap each plugin lib (hlint, brittany, floskell, etc) or sets of plugins in a executable+lsp stdio+ghc interface wrapper and distribute the precompiled executables separately.

[ndmitchell]

@jneira many plugins are going to require a GHC session. Either you can duplicate the GHC session to different processes (which is incredibly expensive in CPU terms), or marshal every GHC API call over to the GHC session (incredibly expensive in terms of communication). It would be nice if we could figure out a way that works, but I can't think of one.

[jneira]

Mmm i see. Thanks for sharing.

So add to the ide server a bridge between the ghc session and the plugins using a lsp-like format is not viable 😞

Still, could plugins not using the ghc session be isolated? Dont know much about each tool internals but maybe any of hoogle, hlint, liquid or any of formatters dont use a ghc session???

[ndmitchell]

Most plugins are likely to get something from the GHC environment - the parse tree, the text after preprocessing, the names on which to run searches. Looking at HLint and formatters like Ormulu, they should be using the GHC environment (they currently build their own GHC environment, which is a bit different).

[alanz]

@jneira the approach fpcomplete took in their initial web-ide backend took that approach, and I understand had major issues with just sharing data between the various processes.

[alanz]

Plus the prospect of the kinds of issues that will be raised because people are not able to get a set of separate processes running and talking to each other is not good. Think our current stuff x 10.

[jneira]

Sorry if i am adding a lot of nosense but i think @mpickering mentioned a library that tried to eval haskell code at runtime than maybe could be useful: not sure if it was https://github.com/stepcut/plugins

[fendor]

Out of curiosity, did you have time to touch debugger integration? Or is it too soon to talk about such a feature?

[alanz]

Out of curiosity, did you have time to touch debugger integration? Or is it too soon to talk about such a feature?

We had a brief conversation, which did not go anywhere in particular. I think it is something that needs to happen, sometime, but we first need to get over the initial process. Once haskell-ide is available for use, we can consider additional stuff.

[alanz]

Just dumping this here, thoughts on range formatting. haskell/haskell-ide-engine#1602 (comment)

[NightRa]

Sounds like a perfect use case for dynamic linking @jneira @ndmitchell

[jneira]

Another question: could we continue using the hie solution to handle several ghcs using a wrapper?
I think it could be more beginner friendly although it has a point of friction trying to guess the ghc version used in a project.

Somewhat philosophical side note: it seems to me that ghcide is more used by (suited to?) experienced haskell developers. I think we have the opportunity and the challenge to build a tool well-balanced between beginners and more experienced haskell devs.

[jneira]

@NightRa coming from the jvm world, where it is the default way to go, i think so.
However i am not sure if it is widely used enough in the haskell world to not hit a lot of pain points (performance, bugs, etc, etc)