Find alternative to parsing GHCi output

[bgamari]

Currently haskell-mode seems to rely on a pile of rather fragile regular expressions for getting information out of GHCi. However, GHCi is not intended to be a language server; rather, it is a REPL for use by humans. As such, the GHC developers reserve the right to change output freely to improve ghci's usability for its intended purpose.

Unfortunately, when we exercise that right we end up with situations like #1553. The solution is here is clear: let's define a machine-readable interface. Perhaps it will be part of ghci or perhaps not. But let's begin the discussion. What does haskell-mode need out of GHCi to work robustly and avoid parsing-by-way-of-regular-expression?

In the case of #1553 I have introduced a flag reverting the output to the previous behavior. However, be aware that I would like to deprecate this flag soon; let's starting feeling out alternatives so I can do that.

[hvr]

To be fair, there are already a handful of GHCi commands which are intended to be used by machines which I either implemented or ported myself to GHCi (and whose output was designed with a connsumer such as Emacs in mind), and whose output is thus properly specified in the user's guide. This of course doesn't apply to the screen-scraping @bgamari is referring to.

Consequently I'd claim, that every command whose output isn't explicitly defined in the user's guide is subject to change w/o prior notice.

[bgamari]

Herbert Valerio Riedel <[email protected]> writes:

Consequently I'd claim, that every command whose output isn't explicitly defined in the user's guide is subject to change w/o prior notice.

Yes, I should have been more clear. This is true; that being said, I think even their purpose would be better served by a more structured, machine-readable interface.

[bgamari]

For the record, I have opened a GHC ticket where we can collect design ideas. Please do chime in; we would love to improve GHC's tooling story but we need your input to do so.