[prev in list] [next in list] [prev in thread] [next in thread]
List: haskell-cafe
Subject: Re: [Haskell-cafe] type error when specializing lens zooms in ghc >= 9.0
From: Bryan Richter via Haskell-Cafe <haskell-cafe () haskell ! org>
Date: 2023-06-27 6:06:33
Message-ID: CACUTo6zipW_gSyRuzJ3ibNURq2b2j8-Wo5F54F=iuZ=eMi6YTw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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 <olf@aatal-apotheke.de> wrote:
> > 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:
> >
> >
> >
> https://gitlab.haskell.org/search?search=83865&project_id=1&group_id=2&search_code=true&repository_ref=master
>
> >
> > 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/Codes.hs
> [2]
> https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Tc.Errors.Types.html#TypeEqMismatch
> [3]
> https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Core.TyCo.Rep.html#ForAllTy
> [4]
> https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Tc.Errors.Ppr.html#pprMismatchMsg
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><div>Hi Olaf,</div><div><br></div><div>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.</div><div><br></div><div>I added some of your \
suggestions to the ticket.<br></div><div><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 2 Jun 2023 at 17:16, \
Olaf Klinke <<a href="mailto:olf@aatal-apotheke.de">olf@aatal-apotheke.de</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Hm, yikes, I tend \
to agree this is a very general error message. Here<br> > are<br>
> all the places "83865" shows up in the code base:<br>
> <br>
> <br>
> <a href="https://gitlab.haskell.org/search?search=83865&project_id=1&group_id=2&search_code=true&repository_ref=master" \
rel="noreferrer" target="_blank">https://gitlab.haskell.org/search?search=83865&project_id=1&group_id=2&search_code=true&repository_ref=master</a><br>
> <br>
> I opened <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/23466" \
rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/issues/23466</a> \
to follow<br> > up.<br>
> Feel free to weigh in. (Contact me if you need an account - spam<br>
> measures<br>
> currently include manual approvals for new accounts.)<br>
> <br>
<br>
Thanks, Bryan. <br>
<br>
This made me wonder what the current system behind assignment of error<br>
codes is. I'd expect five-digit error codes to be *more* specific than<br>
the general shape of error message emitted by ghc, but here it is<br>
evidently less specific. 82865 stands for the error message constructor<br>
TypeEqMismatch [1] which is a record [2] with many fields. In<br>
particular, the teq_mismatch_expected and teq_mismatch_actual fields<br>
hold structural information: a ForAllTy [3] may hint at simplified<br>
subsumption. <br>
<br>
Thus my proposal would be that error codes are composite values, with<br>
one part (as currently implemented) in bijection to the error message<br>
constructor and another part determined by a function of the actual<br>
error value. This function has to be chosen to provide sufficient<br>
abstraction from the actual situation but e.g. differentiate between<br>
constructors of the Type type. For example, why don't the cases<br>
differentiated by the pretty-printer [4] not own their own error codes?<br>
<br>
Olaf<br>
<br>
[1] <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Types/Error/Codes.hs" \
rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Types/Error/Codes.hs</a><br>
[2] <a href="https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Tc.Errors.Types.html#TypeEqMismatch" \
rel="noreferrer" target="_blank">https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Tc.Errors.Types.html#TypeEqMismatch</a><br>
[3] <a href="https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Core.TyCo.Rep.html#ForAllTy" \
rel="noreferrer" target="_blank">https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Core.TyCo.Rep.html#ForAllTy</a><br>
[4] <a href="https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Tc.Errors.Ppr.html#pprMismatchMsg" \
rel="noreferrer" target="_blank">https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Tc.Errors.Ppr.html#pprMismatchMsg</a><br>
<br>
</blockquote></div>
[Attachment #6 (text/plain)]
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic