#15461: Machine accessible interface to GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description:
For a long time tooling users (e.g. `haskell-mode`) have been treating GHCi as a language server. As one would expect this leads to a frustrating situation for both GHC developers (who feel constrained in their ability to change output) and users (who occasionally suffer breakage, e.g. [[https://github.com/haskell/haskell- mode/issues/1553#issuecomment-409267399]]).
Ultimately the solution seems fairly clear:
1. allow GHCi to expose multiple REPL interfaces (e.g. such that a user could have multiple textual REPLs open, all served by the same GHCi session) 2. add a machine-readable request protocol to GHCi, giving tooling users a way to use GHCi's functionality without parsing human-readable output
(1) should be fairly straightforward to implement. There are a few decisions to be made, which will largely be driven by user needs:
* what sort of channels do we support (e.g. TCP/IP sockets, Unix domain sockets, only pipes?) * how does one open a new channel? * are the `std{in,out,err}` handles redirected? For instance, if multiple channels request execution of `putStrLn "hello world"` who gets the output? There are three options, a. neither requester gets any output b. both channels get two "hello world" messages c. each channel gets precisely the output from its evaluation
(c) would be quite hard to do although an approximation could potentially be accomplished by hacking `GHC.IO.Handle.FD`.
(2) on the other hand requires some design work (e.g. what does the wire protocol look like?) and a fair bit of refactoring (to expose the existing commands in a machine-readable manner).
== Possible users == Users of this facility might include,
* [[https://github.com/haskell/haskell-mode/|haskell-mode]] * [[https://github.com/gibiansky/IHaskell|IHaskell]] * Intero?
New description: For a long time tooling users (e.g. `haskell-mode`) have been treating GHCi as a language server. As one would expect this leads to a frustrating situation for both GHC developers (who feel constrained in their ability to change output) and users (who occasionally suffer breakage, e.g. [[https://github.com/haskell/haskell- mode/issues/1553#issuecomment-409267399]]). Ultimately the general shape of the solution seems fairly clear: 1. allow GHCi to expose multiple REPL interfaces (e.g. such that a user could have multiple textual REPLs open, all served by the same GHCi session) 2. add a machine-readable request protocol to GHCi, giving tooling users a way to use GHCi's functionality without parsing human-readable output (1) should be fairly straightforward to implement. There are a few decisions to be made, which will largely be driven by user needs: * what sort of channels do we support (e.g. TCP/IP sockets, Unix domain sockets, only pipes?) * how does one open a new channel? * are the `std{in,out,err}` handles redirected? For instance, if multiple channels request execution of `putStrLn "hello world"` who gets the output? There are three options, a. neither requester gets any output b. both channels get two "hello world" messages c. each channel gets precisely the output from its evaluation (c) would be quite hard to do although an approximation could potentially be accomplished by hacking `GHC.IO.Handle.FD`. (2) on the other hand requires some design work (e.g. what does the wire protocol look like?) and a fair bit of refactoring (to expose the existing commands in a machine-readable manner). == Possible users == Users of this facility might include, * [[https://github.com/haskell/haskell-mode/|haskell-mode]] * [[https://github.com/gibiansky/IHaskell|IHaskell]] * Intero? -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15461#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler