<div dir="ltr"><div>To me this is just further evidence that we need a first class API for tool makers.  Which is a (slow) work in progress.<br><br></div>Alan<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 6 November 2017 at 19:46, Sven Panne <span dir="ltr"><<a href="mailto:svenpanne@gmail.com" target="_blank">svenpanne@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">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></span><div>Yep, will do...</div><span class=""><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></span><div>Thanks for the quick fix!</div><span class=""><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></span><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><span class=""><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></span><div>That's of course not what was proposed. :-)</div><span class=""><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></span><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>
<br>______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
Only members subscribed via the mailman list are allowed to post.<br></blockquote></div><br></div>