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. It would be a shame to avoid changes which make the user experience better simply because other projects cannot sync their development cycle, especially if those projects are not universally used or required. Thanks, Jonathan On November 5, 2017 6:56:53 AM CST, Sven Panne wrote:

This is not an issue about 8.2.2 per se, but 8.2 changes in general: Recent discussions on Haskell Cafe showed serious problems with Emacs' haskell-mode due to some ad hoc changes like https://phabricator.haskell.org/D3651. Related GitHub issues:

https://github.com/haskell/haskell-mode/issues/1553 https://github.com/haskell/haskell-mode/issues/1496

It should be noted that the output of GHC(i) is actually part of GHC's interface, so in this light, there have been some breaking changes, probably unintended, but nevertheless. So my question is: Is there a chance to revert some of these ad hoc changes and/or add some flags to get the old behavior back? I guess that Emacs + haskell-mode is one of the most important IDEs, so it would be a pity to worsen the situation there.

I'm quite aware that it is very late in the release cycle, but it would be extremely nice if there was something which can be done. In the future it might make sense to co-operate with the haskell-mode team a bit more, perhaps adding some tests regarding the required output format etc. to GHC's test suite.

Cheers, S.

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

2017-11-05 19:29 GMT+01:00 Viktor Dukhovni :

Amen to that. I find the diagnostic output of 8.2 substantially improved (more useful in locating the reported bugs) over previous versions. So reverting to previous behaviour would not be a good idea.

I didn't propose that, just a way to *optionally* get the old behavior back until we blissfully live in a world with a stable machine-readable interface.

It should not take too long for the relevant emacs modules to be updated. And they should be made more forgiving of small changes in the output format (use less precise regular expressions).

If I understand the tickets correctly, there is a loss of information, so this might not be possible. OTOH, I don't fully understand how haskell-mode works under the hood... Cheers, S.

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

To me this is just further evidence that we need a first class API for tool makers. Which is a (slow) work in progress. Alan On 6 November 2017 at 19:46, Sven Panne wrote:

2017-11-06 17:54 GMT+01:00 Ben Gamari :

...

Next time something like this arises please do open a ticket.

Yep, will do...

...

Yes, I have opened a differential adding such a flag. See D4164 [1]. Please bikeshed to taste.

Thanks for the quick fix!

...

In general I would really prefer that we *not* consider GHCi's REPL to be a stable programmatic interface.

I fully understand that, and that's definitely the way to go. Nevertheless, parsing tool/compiler output is still one of the most used hacks^H^H^H techniques for lots of Emacs modes (and probably other IDEs). Not every project is as open to suggestions and changes as GHC is, so this is often the only way out.

...

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.

That's of course not what was proposed. :-)

...

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.

I think the main problem here was communication. I can't speak for the haskell-mode maintainers, but for my part I didn't notice the problems because I mainly use LTS Stackage and that is still(!) at 8.0.2 (Why? This is definitely part of the whole problem.). I tried the 8.2 series only sparingly and only via the command line, so this is perhaps what others did, too, so the interaction bug went unnoticed for such a long time.

Cheers, Sven

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

As the author of that diff, I agree that making it optional is the right thing to do here -- and in fact I think my first version had that behavior under a flag. It shouldn't be hard to introduce such a flag, but I don't know if I have time to do it before 8.2.2 is released... I'd be happy to help other volunteers, you can ping me on #ghc, I'm bitonic. Francesco On Sun, Nov 5, 2017 at 10:12 PM, Evan Laforge wrote:

On Sun, Nov 5, 2017 at 4:56 AM, Sven Panne wrote:

...

This is not an issue about 8.2.2 per se, but 8.2 changes in general: Recent discussions on Haskell Cafe showed serious problems with Emacs' haskell-mode due to some ad hoc changes like https://phabricator.haskell.org/D3651.

I've long used ghci -v0 to achieve the same effect. When you have a couple hundred modules the "loaded X Y Z" is worse than useless. But it's better to just add -v0, and maybe add more flags for finer control, than change the default and break tools. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Francesco Mazzoli Senior Software Engineer c: +39 3200346394 e: francesco.mazzoli@digitalasset.com  Digital Asset (Switzerland) GmbH Luggwegstrasse 9 8048 Zurich, Switzerland digitalasset.com -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.