
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
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.