<div dir="auto">And just generally having a short code and descriptive name both, allows useful toooling and human communication. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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 ?</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 2, 2021 at 11:24 AM Ruben Astudillo <<a href="mailto:ruben.astud@gmail.com">ruben.astud@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am no GHC developer, so this is not my place to reply. Even though I<br>
humbly would like to put an argument in favor of numbers.<br>
<br>
On 02-06-21 06:46, Tom Ellis wrote:<br>
> On Tue, Jun 01, 2021 at 03:40:57PM -0700, Alec Theriault wrote:<br>
>> Rust has taken an interesting approach for this: every error message is<br>
>> given a unique number like "E0119"<br>
> <br>
> Is there a particularly strong reason to use numbers as codes when we<br>
> have the entire space human-readable strings available to us?  Even<br>
> the subset of case-insensitive strings formed from alphanumeric<br>
> characters plus underscore seems more suitable for the encoding than<br>
> positive integers.<br>
> <br>
> e.g. "conflicting_trait_implementations" seems better than "E0119"<br>
<br>
One is SEO-optimization. A number like #0119 on a search string like "ghc<br>
error #0119" ought to have as a first result the GHC user docs. This is a<br>
great user experience for students. A more general search string can have<br>
more results on other languages and is difficult to say we would be first<br>
result.<br>
<br>
Second one is that a number is shorter than a general string. That way we<br>
can highlight it on a error message on the terminal without occupying to<br>
much space. Current messages in GHC are already too big.<br>
<br>
-- <br>
-- Rubén<br>
-- pgp: 4EE9 28F7 932E F4AD<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div>