[GHC] #15461: Machine accessible interface to GHCi
#15461: Machine accessible interface to GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 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). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15461 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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
#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?
(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). Users of this 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:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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?
(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).
Users of this 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 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:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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
#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: | -------------------------------------+------------------------------------- Comment (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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15461#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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: | -------------------------------------+------------------------------------- Changes (by dpwiz): * cc: dpwiz (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15461#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:5 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15461#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#15461: Machine accessible interface to GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.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: | -------------------------------------+------------------------------------- Comment (by alanz): There was a discussion on IRC a while back, the record is here: https://gist.github.com/alanz/8f6325c670247f51fbd31c78692c4d66 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15461#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#15461: Machine accessible interface to GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.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: | -------------------------------------+------------------------------------- Comment (by alanz): See also https://github.com/haskell/haskell-ide-engine/issues/1053 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15461#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#15461: Machine accessible interface to GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.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: | -------------------------------------+------------------------------------- Changes (by redneb): * cc: redneb (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15461#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC