Thanks Erik. Error message quality is crucial, as you say.
But it's a very hard thing to measure, because it's a matter of human judgement. For example, you suggest
| I would like to suggest that a prerequesite for merging of new features would
| be that it provides good error messages and more importantly does not provide
| wrong or misleading error messages like the one above.
That is an excellent goal. But I don't know how to verify whether a patch meets that goal. GHC has several thousand regression tests; if the error message changes that is part of the patch, and is subject to code review. But it's harder to review the effect on test cases we'd never thought of, like yours.
The only feasible way I know is for GHC's users to submit bug reports, showing a bad error message, with a way to reproduce it in a small test case, and a suggestions for what would be a better one. That way, hopefully one of GHC's contributors will find a way to fix it.
Might you do that for your example (which I do not yet understand)? That's would be really helpful. It can take a little work to distil a small test case, but well-characterised bug reports are a major way in which GHC's users can contribute directly to improving GHC's quality.
Thanks
Simon
| -----Original Message-----
| From: ghc-devs On Behalf Of Erik de Castro
| Lopo
| Sent: 17 July 2020 05:11
| To: ghc-devs@haskell.org
| Subject: Error messages
|
| Hi all,
|
| Although it was many years ago I did spend soem time working on GHC
| and I do know what a thankless task it is. I made a compliant about
| GHC error messages on an internal Slack channel and Mortiz encouraged
| me to repeat it here.
|
| I am incredibly happy about the quality of error messges for older
| more standard parts of Haskell, probably most things in Haskell98
| and Haskell2010.
|
| By way of contrast, error messages for some newer parts of Haskell are
| incredibly poor. In fact, for the new parts, the error rmessages are
| often wrong, just defaulting to error messages for older parts of
| Haskell.
|
| As an example (open source code in a public GH repo):
|
| src/Cardano/DbSync/StateQuery.hs:87:44: error:
| • Data constructor not in scope:
| QueryAnytime
| :: QueryHardFork xs0 (Interpreter xs0)
| -> Query
| (CardanoBlock TPraosStandardCrypto)
| (Interpreter (CardanoEras TPraosStandardCrypto))
| • Perhaps you want to add ‘QueryAnytime’ to the import list
| in the import of
| ‘Ouroboros.Consensus.HardFork.Combinator.Ledger.Query’
| (src/Cardano/DbSync/StateQuery.hs:49:1-116).
| |
| 87 | queryHistoryInterpreter connInfo (point, QueryAnytime
| GetInterpreter)
|
| The suggestion is that I need to import `QueryAnytime` but just 20 line
| above I
| have:
|
| import Ouroboros.....Query (QueryAnytime (..), QueryHardFork
| (GetInterpreter))
|
| The problem is that `QueryAnytime` is defined as a pattern synonym. I
| have only
| the tinest amount of experience using pattern synonyms and that error
| message
| is not really useful.
|
| I would like to suggest that a prerequesite for merging of new features
| would
| be that it provides good error messages and more importantly does not
| provide
| wrong or misleading error messages like the one above.
|
| Erik
| --
| ----------------------------------------------------------------------
| Erik de Castro Lopo
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mega
| -
| nerd.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cb97ca052f89f4363
| 73c508d82a076974%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63730555861
| 2145985&sdata=BbxTaOA9jhXbEX%2BmgZcwa0AjkZv8H58cgn0sCXgUwCU%3D&re
| served=0
| _______________________________________________
| ghc-devs mailing list
| ghc-devs@haskell.org
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has
| kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cb97ca052f89f436373c508d
| 82a076974%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305558612145985
| &sdata=yPnFMY3iqnBT8%2FMQTWiVg3aE1Ya%2BWxyqfjszc3XOMLw%3D&reserve
| d=0
