GHC typecheck API
nboldi at elte.hu
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).
2017.12.01. 4:12 keltezéssel, Christopher Done írta:
> I suppose setting -fdefer-type-errors would also be handy in this
> 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.
> | -----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
> | code (correcting parenthesis problems, like 'putStrLn "xxx" ++
> show a'
> | ==> 'putStrLn ("xxx" ++ show a)'). To do that I need to get the
> | 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>
> | ell.org <http://ell.org>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> | devs&data=02%7C01%7Csimonpj%40microsoft.com
> | ta=Kf5rZYwht8ZGBtGNNH6Q44wLIeefxzHn2UfDIdrNNMU%3D&reserved=0
> ghc-devs mailing list
> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs