GHC typecheck API

Fri Dec 1 02:49:16 UTC 2017

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 at haskell.org <mailto: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.
>
>     Simon
>
>       | -----Original Message-----
>     | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org
>     <mailto:ghc-devs-bounces at haskell.org>] On Behalf Of Németh
>     | Boldizsár
>     | Sent: 30 November 2017 05:42
>     | To: ghc-devs at haskell.org <mailto: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 <http://haskelltools.org>
>     |
>     | _______________________________________________
>     | ghc-devs mailing list
>     | ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     |
>     https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
>     | ell.org <http://ell.org>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
>     | devs&data=02%7C01%7Csimonpj%40microsoft.com
>     <http://40microsoft.com>%7C364b8db55e064415650d08d537b
>     |
>     5323f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636476173738772433&sda
>     | ta=Kf5rZYwht8ZGBtGNNH6Q44wLIeefxzHn2UfDIdrNNMU%3D&reserved=0
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171201/50ed5b84/attachment.html>