Opened 5 months ago

Last modified 4 months ago

#15461 new feature request

Machine accessible interface to GHCi

Reported by: bgamari Owned by:
Priority: normal Milestone: 8.8.1
Component: GHCi Version: 8.4.3
Keywords: newcomer Cc: alanz, dpwiz
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 (last modified by bgamari)

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,
    1. neither requester gets any output
    2. both channels get two "hello world" messages
    3. 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,

Change History (9)

comment:1 Changed 5 months ago by bgamari

Description: modified (diff)

comment:2 Changed 5 months ago by bgamari

Description: modified (diff)

comment:3 Changed 5 months ago by bgamari

Description: modified (diff)

comment:4 Changed 5 months ago by bgamari

Description: modified (diff)

comment:5 Changed 5 months ago by alanz

An interim step would be to add tests to ghc/ghci that explicitly exercise the features currently used in haskell-mod and/or Intero, so that we get an early warning on any of these changing.

comment:6 Changed 5 months ago by dpwiz

Cc: dpwiz added

comment:7 in reply to:  5 Changed 5 months ago by hvr

Replying to alanz:

An interim step would be to add tests to ghc/ghci that explicitly exercise the features currently used in haskell-mod and/or Intero

Note that Intero is irrelevant in this context; Intero started as a fork of http://hackage.haskell.org/package/ghci-ng-7.6.3.5 and has diverged from GHCi's roots ever since without contributing back. So let's just focus on haskell-mode and keep Intero out of this please.

comment:8 Changed 4 months ago by bgamari

Milestone: 8.6.18.8.1

These won't be fixed for in GHC 8.6.

comment:9 Changed 4 months ago by alanz

There was a discussion on IRC a while back, the record is here: https://gist.github.com/alanz/8f6325c670247f51fbd31c78692c4d66

Note: See TracTickets for help on using tickets.