<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-11-06 17:54 GMT+01:00 Ben Gamari <span dir="ltr"><<a href="mailto:ben@well-typed.com" target="_blank">ben@well-typed.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Next time something like this arises please do open a ticket.<br></blockquote><div><br></div><div>Yep, will do...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yes, I have opened a differential adding such a flag. See D4164 [1].<br>
Please bikeshed to taste.<br></blockquote><div><br></div><div>Thanks for the quick fix!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In general I would really prefer that we *not* consider GHCi's REPL to be<br>
a stable programmatic interface.</blockquote><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
That being said, we cannot always preemptively add complexity to the<br>
project out of fear that a given change might break a hypothetical<br>
mechanical consumer.</blockquote><div><br></div><div>That's of course not what was proposed. :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> GHCi is first-and-foremost a REPL for users.<br>
When evaluating a change, if we feel it is likely that we will break a<br>
mechanical user then we will likely guard the change with a flag.<br>
However, if not, we won't.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>   Sven</div></div></div></div>