[GHC] #15461: Machine accessible interface to GHCi

[GHC]

#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. (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).

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 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?

 (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).

--

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15461#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler