<div dir="ltr">We're currently experimenting with this for Intero. There does seem to be a significant performance reduction with -fdefer-type-errors:<div><br></div><div><a href="https://github.com/commercialhaskell/intero/pull/495#issuecomment-348474127">https://github.com/commercialhaskell/intero/pull/495#issuecomment-348474127</a><br></div><div><br></div><div>It's a classic cost benefit scenario: the benefits are much more type info available, including go to definition and things like that being more immediately up to date. The cost is having to wait more time.</div><div><br></div><div>I believe if there's a good compromise to this, it'll probably involve sometimes enabling -fdefer-type-errors and most of the time turning it off for immediate feedback.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 1 December 2017 at 02:49, Németh Boldizsár <span dir="ltr"><<a href="mailto:nboldi@elte.hu" target="_blank">nboldi@elte.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Thank you for the suggestions!</p>
<p>Setting the -fdefer-type-errors flag is indeed a good way to do
it (with also adding Opt_DeferTypedHoles and
Opt_DeferOutOfScopeVariables for other kind of errors).<span class="HOEnZb"><font color="#888888"><br>
</font></span></p><span class="HOEnZb"><font color="#888888">
<p>Boldizsár<br>
</p></font></span><div><div class="h5">
<br>
<div class="m_-5235139991744499796moz-cite-prefix">2017.12.01. 4:12 keltezéssel,
Christopher Done írta:<br>
</div>
<blockquote type="cite">
<div>
<div dir="auto">I suppose setting -fdefer-type-errors would also
be handy in this scenario!</div>
<br>
<div class="gmail_quote">
<div>On Thu, 30 Nov 2017 at 15:37, Simon Peyton Jones via
ghc-devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This
sounds like a good project!<br>
<br>
For the most part things look good:<br>
<br>
* Most type checker errors arise from *type constraints*.
The type checkder tries to solve these, but returns an
elaborated syntax tree (i.e. typechecked, and annotated with
types) even if constraint solving fails.<br>
<br>
* Some renamer errors are like this, notably out-of-scope
variables. (They just show up as another constraint.)<br>
<br>
However there is historical baggage. Back in the beginning,
most errors were treated by throwing an exception in the
typechecker monad; such exceptions can be caught, so that we
can get more than one error from the file, but no syntax
tree is returned. Example<br>
let f = <expression> in <body><br>
If there was an error in <expression> we'd throw an
exception, catch it at the 'let', give 'f' the type<br>
f :: forall a. a<br>
and continue to typecheck <body>.<br>
<br>
The trouble with the exception stuff is that you don't get
an elaborated syntax tree.<br>
<br>
So: I think you can get some of the way today, just by
returning the tree anyway even if there is an error to
report. But it'd take a bit more work to make more and more
errors into things that don't throw an exception. (Look for
failTc, failRn in thd code.)<br>
<br>
I'm not very familiar with the GHC API for this part, but
others will be. I'm certain it can be improved, so rather
than hacking around what is there already, do propose and
implement improvements.<br>
<br>
Simon<br>
<br>
| -----Original Message-----<br>
| From: ghc-devs [mailto:<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">ghc-devs-bounces@<wbr>haskell.org</a>]
On Behalf Of Németh<br>
| Boldizsár<br>
| Sent: 30 November 2017 05:42<br>
| To: <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
| Subject: GHC typecheck API<br>
|<br>
| Dear GHC developers,<br>
|<br>
| I'm developing a framework for development tools for
Haskell. I use the<br>
| GHC API to parse and typecheck the source files. I
recently started to<br>
| work on a quick-fix (automatic program correction) for
Haskell source<br>
| code (correcting parenthesis problems, like 'putStrLn
"xxx" ++ show a'<br>
| ==> 'putStrLn ("xxx" ++ show a)'). To do that I need to
get the typed<br>
| syntax tree even if the program contains type or rename
errors. I could<br>
| only do this by a nasty hack, adding a new TH module
finalizer<br>
| (tcg_th_modfinalizers) to extract the type checker's state
before it<br>
| fails. Is there a "correct" way to do this? I would not
like this<br>
| refactorings to be unusable if the GHC API changes.<br>
|<br>
| By the way, if you know of any similar attempt please let
me know.<br>
|<br>
| Sincerely,<br>
| Boldizsár Németh<br>
| <a href="http://haskelltools.org" rel="noreferrer" target="_blank">haskelltools.org</a><br>
|<br>
| ______________________________<wbr>_________________<br>
| ghc-devs mailing list<br>
| <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
| <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask" rel="noreferrer" target="_blank">https://na01.safelinks.<wbr>protection.outlook.com/?url=<wbr>http%3A%2F%2Fmail.hask</a><br>
| <a href="http://ell.org" rel="noreferrer" target="_blank">ell.org</a>%2Fcgi-bin%2Fmailman%<wbr>2Flistinfo%2Fghc-<br>
| devs&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40<wbr>microsoft.com</a>%<wbr>7C364b8db55e064415650d08d537b<br>
|
5323f%<wbr>7C72f988bf86f141af91ab2d7cd011<wbr>db47%7C1%7C0%<wbr>7C636476173738772433&sda<br>
|
ta=<wbr>Kf5rZYwht8ZGBtGNNH6Q44wLIeefxz<wbr>Hn2UfDIdrNNMU%3D&reserved=0<br>
______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>