value of documenting error messages?

[Tom Ellis]

On Wed, Jun 02, 2021 at 11:22:47AM -0400, Ruben Astudillo wrote:
> I am no GHC developer, so this is not my place to reply. Even though I
> humbly would like to put an argument in favor of numbers.

The issue of error codes impinges more on GHC users than GHC
developers (although it's also a bit tangential to Richard's original
post).

> On 02-06-21 06:46, Tom Ellis wrote:
> > On Tue, Jun 01, 2021 at 03:40:57PM -0700, Alec Theriault wrote:
> >> Rust has taken an interesting approach for this: every error message is
> >> given a unique number like "E0119"
> > 
> > Is there a particularly strong reason to use numbers as codes when we
> > have the entire space human-readable strings available to us?  Even
> > the subset of case-insensitive strings formed from alphanumeric
> > characters plus underscore seems more suitable for the encoding than
> > positive integers.
> > 
> > e.g. "conflicting_trait_implementations" seems better than "E0119"
> 
> One is SEO-optimization. A number like #0119 on a search string like "ghc
> error #0119" ought to have as a first result the GHC user docs. This is a
> great user experience for students. A more general search string can have
> more results on other languages and is difficult to say we would be first
> result.
> 
> Second one is that a number is shorter than a general string. That way we
> can highlight it on a error message on the terminal without occupying to
> much space. Current messages in GHC are already too big.

I'm surprised by the responses to the idea of descriptive error codes
(not just Ruben's response).

"ghc error #0119" seems like no better a search string than "ghc error
conflicting_trait_implementations" (and I can concoct reasons why it
would be worse).  Non-descriptive error codes risk being buried in
results about food additives[1] amongst myriad other things.

If we really think that non-descriptive codes are the clearest way to
communicate between machines and humans then I wonder if we should
rename `mapAccumL` to `F392` and `TypeFamilies` to `X56`.

Tom

[1] https://en.wikipedia.org/wiki/E_number#Full_list