The report is timing how long a `:load` takes. Sure, if/when I reproduce this on some open source module I'll make a ticket with a test case!
On 1 December 2017 at 12:03, Simon Peyton Jones <simo...@microsoft.com> wrote: > There does seem to be a significant performance reduction with > -fdefer-type-errors: > > https://github.com/commercialhaskell/intero/pull/ > 495#issuecomment-348474127 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcommercialhaskell%2Fintero%2Fpull%2F495%23issuecomment-348474127&data=02%7C01%7Csimonpj%40microsoft.com%7Cee995eabce464843128408d538b33205%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636477264644187140&sdata=0ZgJ1a56kaIfB9U2vnnf2lIQvP%2BOu26fMnE9sV8xDn4%3D&reserved=0> > > > > That’s odd. I would expect zero effect if there aren’t any errors, and not > much even if ther are. It’s not clear whether the report is to do with > compile time or runtime. > > > > If you can boil down a test case, maybe a ticket would be good > > > > *From:* Christopher Done [mailto:chrisd...@gmail.com] > *Sent:* 01 December 2017 12:01 > *To:* Németh Boldizsár <nbo...@elte.hu> > *Cc:* Simon Peyton Jones <simo...@microsoft.com>; ghc-devs@haskell.org > *Subject:* Re: GHC typecheck API > > > > We're currently experimenting with this for Intero. There does seem to be > a significant performance reduction with -fdefer-type-errors: > > > > https://github.com/commercialhaskell/intero/pull/ > 495#issuecomment-348474127 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcommercialhaskell%2Fintero%2Fpull%2F495%23issuecomment-348474127&data=02%7C01%7Csimonpj%40microsoft.com%7Cee995eabce464843128408d538b33205%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636477264644187140&sdata=0ZgJ1a56kaIfB9U2vnnf2lIQvP%2BOu26fMnE9sV8xDn4%3D&reserved=0> > > > > 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. > > > > 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. > > > > > > > > On 1 December 2017 at 02:49, Németh Boldizsár <nbo...@elte.hu> wrote: > > Thank you for the suggestions! > > 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). > > Boldizsár > > > > 2017.12.01. 4:12 keltezéssel, Christopher Done írta: > > I suppose setting -fdefer-type-errors would also be handy in this scenario! > > > > On Thu, 30 Nov 2017 at 15:37, Simon Peyton Jones via ghc-devs < > ghc-devs@haskell.org> wrote: > > This sounds like a good project! > > For the most part things look good: > > * 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. > > * Some renamer errors are like this, notably out-of-scope variables. > (They just show up as another constraint.) > > 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 > let f = <expression> in <body> > If there was an error in <expression> we'd throw an exception, catch it at > the 'let', give 'f' the type > f :: forall a. a > and continue to typecheck <body>. > > The trouble with the exception stuff is that you don't get an elaborated > syntax tree. > > 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.) > > 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. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Németh > | Boldizsár > | Sent: 30 November 2017 05:42 > | To: ghc-devs@haskell.org > | Subject: GHC typecheck API > | > | Dear GHC developers, > | > | I'm developing a framework for development tools for Haskell. I use the > | GHC API to parse and typecheck the source files. I recently started to > | work on a quick-fix (automatic program correction) for Haskell source > | code (correcting parenthesis problems, like 'putStrLn "xxx" ++ show a' > | ==> 'putStrLn ("xxx" ++ show a)'). To do that I need to get the typed > | syntax tree even if the program contains type or rename errors. I could > | only do this by a nasty hack, adding a new TH module finalizer > | (tcg_th_modfinalizers) to extract the type checker's state before it > | fails. Is there a "correct" way to do this? I would not like this > | refactorings to be unusable if the GHC API changes. > | > | By the way, if you know of any similar attempt please let me know. > | > | Sincerely, > | Boldizsár Németh > | haskelltools.org > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskelltools.org&data=02%7C01%7Csimonpj%40microsoft.com%7Cee995eabce464843128408d538b33205%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636477264644187140&sdata=4i0ZmhAEE7BdevNS9u6ij8a3awBsxN4qoqCN1t7BFeU%3D&reserved=0> > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs@haskell.org > | https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fmail.hask > | ell.org > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fell.org&data=02%7C01%7Csimonpj%40microsoft.com%7Cee995eabce464843128408d538b33205%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636477264644187140&sdata=okocnHpsBzb1HcwAsxsqRBrd4Da9Yyhb0gDh%2BaPGtyw%3D&reserved=0> > %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devs&data=02%7C01%7Csimonpj%40microsoft.com > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Csimonpj%40microsoft.com%7Cee995eabce464843128408d538b33205%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636477264644187140&sdata=nacoOk3PjrNwByq%2FMDcdO6LL0e2AmdpMDZNQjQ70Ugg%3D&reserved=0> > %7C364b8db55e064415650d08d537b > | 5323f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% > 7C636476173738772433&sda > | ta=Kf5rZYwht8ZGBtGNNH6Q44wLIeefxzHn2UfDIdrNNMU%3D&reserved=0 > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cee995eabce464843128408d538b33205%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636477264644187140&sdata=42Kc793rTA%2Flz4lpGEafkXVgSEwaHtnlnyoxyW4igtk%3D&reserved=0> > > > > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
