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