GHC typecheck API
chrisdone at gmail.com
Fri Dec 1 12:00:41 UTC 2017
We're currently experimenting with this for Intero. There does seem to be a
significant performance reduction with -fdefer-type-errors:
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 <nboldi at 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).
> 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 at 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.
>> | -----Original Message-----
>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
>> | Boldizsár
>> | Sent: 30 November 2017 05:42
>> | To: ghc-devs at 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
>> | _______________________________________________
>> | ghc-devs mailing list
>> | ghc-devs at haskell.org
>> | https://na01.safelinks.protection.outlook.com/?url=
>> | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
>> | devs&data=02%7C01%7Csimonpj%40microsoft.com%
>> | 5323f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
>> | ta=Kf5rZYwht8ZGBtGNNH6Q44wLIeefxzHn2UfDIdrNNMU%3D&reserved=0
>> ghc-devs mailing list
>> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs