<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I'm in favor of short, undescriptive, quite-possibly numeric error codes.<div class=""><br class=""></div><div class="">Advantages:</div><div class="">* Easy to sequentialize. We might have, for example, a "conflicting_trait_implementations" from this year, move on from that design, and then accidentally reintroduce it in a decade, to confusion. Along similar lines, it is easy to write in a comment somewhere what the next error code should be, without having to search the codebase for a use.</div><div class="">* Easy to make compositional. We can choose to have all GHC error codes begin with G (for GHC). Then Cabal could use C, Haddock could use H, and Stack could use S. This makes it easy for users to tell (once they've learned the scheme) where an error has come from.</div><div class="">* Short.</div><div class="">* No chance for misspellings during transcription. When I'm copying a terse identifier, I know I have to get every glyph correct. If I remember that the error code is "bad_generalizing", I might not know how "generalizing" is spelled. I might also forget whether it's "generalizing" or "generalization". And I could very easily see myself making either both of these mistakes as I'm switching from one window to another, in under a second.</div><div class=""><br class=""></div><div class="">Disadvantages:</div><div class="">* The code does not impart semantic meaning. But I argue this is not so bad, as even a more descriptive code does not impart a precise enough semantic meaning to be helpful.</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 2, 2021, at 1:49 PM, Tom Ellis <<a href="mailto:tom-lists-haskell-cafe-2017@jaguarpaw.co.uk" class="">tom-lists-haskell-cafe-2017@jaguarpaw.co.uk</a>> wrote:</div><div class=""><br style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">If we really think that non-descriptive codes are the clearest way to</span><br style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">communicate between machines and humans then I wonder if we should</span><br style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">rename `mapAccumL` to `F392` and `TypeFamilies` to `X56`.</span><br style="caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div></blockquote><div><br class=""></div><div>I think this is a false equivalence. The error codes are meant to be looked up when you see them on your screen, not remembered and then produced at will.</div><div><br class=""></div><div>-------</div><div><br class=""></div><div>Surfacing up a few levels: it sounds like a good next step is not to get all these constructors finely documented, but instead to come up with a way to connect these constructors to user-facing documentation. This might be done by slurping out Markdown from the GHC source code, or perhaps something better. It would be a shame to invest a lot of effort in documenting the constructors in a way that serves only GHC developers, not end users, when we can perhaps do both at the same time.</div><div><br class=""></div><div>Thanks,</div><div>Richard</div></div></div></body></html>