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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
