value of documenting error messages?

[Mario Carneiro]

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 at 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 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
>>
> _______________________________________________
> 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/0047329a/attachment.html>