Rust error codes are not sequential, presumably because some old errors are no longer applicable and new errors get new numbers. It seems to me that it should be possible to just allocate numbers so that if the error changes more than cosmetically then it gets a new number, and thus the error code alone should be sufficient. If a new GHC version changes the meaning of an error message, it should drop the old error code and allocate a new one, so as not to confuse searchers.

On Wed, Jun 2, 2021 at 12:13 PM Carter Schonwald <carter.schonwald@gmail.com> wrote:
And just generally having a short code and descriptive name both, allows useful toooling and human communication. 

If we want to be careful / hedge against errors/ warnings  being slightly different over time, these descriptive names / error codes should also be documented with respect to the ghc version being used. 

For example, I  remember in ghc 8.2 or so for example that for certain type family uses that were actually fine that ghc would warn that allow ambiguous types.  Richard may recall this better than I.  The important piece is that in at least some cases, the full meaning and interpretation of various warnings has definitely changed over ghc versions as various analyses get fancier or simpler or bug fixed. 

So in some respects, at least historically: for sufficiently fancy code, the context of meaning for a given error code / message will only be unambiguous if we interpret it knowing the specific ghc version. 

I presume this will still be true? Should we always talk about error code ghc version pairs rather than error codes? If so should the error rendering be like ghc9_4_1:E2433 as a sortah URI ?

On Wed, Jun 2, 2021 at 11:24 AM Ruben Astudillo <ruben.astud@gmail.com> 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.

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.

--
-- Rubén
-- pgp: 4EE9 28F7 932E F4AD
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs