Re: [Haskell-cafe] type error when specializing lens zooms in ghc >= 9.0
Hm, yikes, I tend to agree this is a very general error message. Here are all the places "83865" shows up in the code base:
I opened https://gitlab.haskell.org/ghc/ghc/-/issues/23466 to follow up. Feel free to weigh in. (Contact me if you need an account - spam measures currently include manual approvals for new accounts.)
Thanks, Bryan. This made me wonder what the current system behind assignment of error codes is. I'd expect five-digit error codes to be *more* specific than the general shape of error message emitted by ghc, but here it is evidently less specific. 82865 stands for the error message constructor TypeEqMismatch [1] which is a record [2] with many fields. In particular, the teq_mismatch_expected and teq_mismatch_actual fields hold structural information: a ForAllTy [3] may hint at simplified subsumption. Thus my proposal would be that error codes are composite values, with one part (as currently implemented) in bijection to the error message constructor and another part determined by a function of the actual error value. This function has to be chosen to provide sufficient abstraction from the actual situation but e.g. differentiate between constructors of the Type type. For example, why don't the cases differentiated by the pretty-printer [4] not own their own error codes? Olaf [1] https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Types/Error/Co... [2] https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Tc.Errors.Types.h... [3] https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Core.TyCo.Rep.htm... [4] https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Tc.Errors.Ppr.htm...
Hi Olaf,
I don't know the precise background to the current system for assignment of
error codes, but I do know that there is ongoing work to provide more
structure to errors. These instances of overly-general codes (and
hypothetically some that may be overly-specific) are artifacts of a rather
young process.
I added some of your suggestions to the ticket.
On Fri, 2 Jun 2023 at 17:16, Olaf Klinke
Hm, yikes, I tend to agree this is a very general error message. Here are all the places "83865" shows up in the code base:
I opened https://gitlab.haskell.org/ghc/ghc/-/issues/23466 to follow up. Feel free to weigh in. (Contact me if you need an account - spam measures currently include manual approvals for new accounts.)
Thanks, Bryan.
This made me wonder what the current system behind assignment of error codes is. I'd expect five-digit error codes to be *more* specific than the general shape of error message emitted by ghc, but here it is evidently less specific. 82865 stands for the error message constructor TypeEqMismatch [1] which is a record [2] with many fields. In particular, the teq_mismatch_expected and teq_mismatch_actual fields hold structural information: a ForAllTy [3] may hint at simplified subsumption.
Thus my proposal would be that error codes are composite values, with one part (as currently implemented) in bijection to the error message constructor and another part determined by a function of the actual error value. This function has to be chosen to provide sufficient abstraction from the actual situation but e.g. differentiate between constructors of the Type type. For example, why don't the cases differentiated by the pretty-printer [4] not own their own error codes?
Olaf
[1] https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Types/Error/Co... [2] https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Tc.Errors.Types.h... [3] https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Core.TyCo.Rep.htm... [4] https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Tc.Errors.Ppr.htm...
participants (2)
-
Bryan Richter -
Olaf Klinke