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 <mailto: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
<mailto:ghc-devs-boun...@haskell.org>] On Behalf Of Németh
| Boldizsár
| Sent: 30 November 2017 05:42
| To: ghc-devs@haskell.org <mailto: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 <http://haskelltools.org>
|
| _______________________________________________
| ghc-devs mailing list
| ghc-devs@haskell.org <mailto:ghc-devs@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@haskell.org <mailto:ghc-devs@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
