Re: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2

Next time something like this arises please do open a ticket. Sven Panne writes:

2017-11-05 15:37 GMT+01:00 :

...

A better approach might be to develop a "machine-readable" output format which then is kept stable, and can be enabled with a flag. Git has a similar solution.

Without doubt, this is definitely the better approach, but this is hardly what can be achieved for 8.2.2. Adding some flag to get the old behavior back when wanted *is* achievable.

Yes, I have opened a differential adding such a flag. See D4164 [1]. Please bikeshed to taste. In general I would really prefer that we *not* consider GHCi's REPL to be a stable programmatic interface. If haskell-mode needs access to some bit of information from GHC, then please let's discuss how to provide it in a more robust manner. This shouldn't be hard; we just need to have feedback on what the interfaces required should look like. [1] https://phabricator.haskell.org/D4164

...

It would be a shame to avoid changes which make the user experience better simply because other projects cannot sync their development cycle,

Don't get me wrong: I'm all for improving user experience, but making ad hoc changes without enough thought or even a chance to get the old behavior back is probably not the right way to proceed. All SW lives in some kind of ecosystem, so it should behave well in that. And for Emacs users, the user experience has been made much worse.

The trouble is that GHC has an extremely large surface area, any bit of which might have mechanical consumers. Those who reviewed the patch indeed considered making this change behind a flag (as Francesco's original patch did) but we concluded that this would be pointless as it didn't seem likely that anyone relied on this behavior. It seems that in this case we were wrong That being said, we cannot always preemptively add complexity to the project out of fear that a given change might break a hypothetical mechanical consumer. GHCi is first-and-foremost a REPL for users. When evaluating a change, if we feel it is likely that we will break a mechanical user then we will likely guard the change with a flag. However, if not, we won't. Cheers, - Ben