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 | | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%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
