value of documenting error messages?

[Carter Schonwald]

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 at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210602/11d6c50f/attachment.html>