Re: value of documenting error messages?

Yes! Thanks for articulating it so nicely On Thu, Jun 3, 2021 at 2:51 PM Alan & Kim Zimmerman wrote: > I think in practical terms for IDE-based people, a short standardised > alphanumeric identifier makes sense. These typically get displayed along > with the full error text in the error pane, an

Re: value of documenting error messages?

By the way, to summarize the discussion on #325, I think the words to use would be "overwhelming support for short numeric reference ids". Here's my argument for it: 1. If you try to make the unique id some mangled form of the error's name, the cognitive burden of crafting errors is increased. Pr

Re: value of documenting error messages?

I think in practical terms for IDE-based people, a short standardised alphanumeric identifier makes sense. These typically get displayed along with the full error text in the error pane, and it helps to be able to allocate a known, standard amount of real estate to them. Fundamentally they are jus

Re: value of documenting error messages?

For what it's worth, there is an existing proposal about this topic, maybe that's the right place to discuss it for a user-focused perspective. See https://github.com/ghc-proposals/ghc-proposals/pull/325 Jakob On Wed, Jun 2, 2021 at 9:10 PM Tom Ellis < tom-lists-haskell-cafe-2...@jaguarpaw.co.uk

Re: value of documenting error messages?

On Wed, Jun 02, 2021 at 07:03:25PM +, Richard Eisenberg wrote: > > To me this seems like a rare opportunity to do something where people > > will say "Hey look, that formidable Haskell compiler is doing > > something that's friendlier than the equivalent in any other > > compiler!". For such a

Re: value of documenting error messages?

> On Jun 2, 2021, at 2:48 PM, Tom Ellis > wrote: > > On Wed, Jun 02, 2021 at 06:13:17PM +, Richard Eisenberg wrote: >> I'm in favor of short, undescriptive, quite-possibly numeric error >> codes. > > These responses are so completely opposite to what I expected that I > can't help thinkin

Re: value of documenting error messages?

On Wed, Jun 02, 2021 at 06:13:17PM +, Richard Eisenberg wrote: > I'm in favor of short, undescriptive, quite-possibly numeric error > codes. These responses are so completely opposite to what I expected that I can't help thinking I've made a fundamental error in my understanding of what we're

Re: value of documenting error messages?

I'm in favor of short, undescriptive, quite-possibly numeric error codes. Advantages: * Easy to sequentialize. We might have, for example, a "conflicting_trait_implementations" from this year, move on from that design, and then accidentally reintroduce it in a decade, to confusion. Along similar

Re: value of documenting error messages?

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 ta

RE: value of documenting error messages?

throw up illuminating info, but is much less precise.) Simon | -Original Message- | From: ghc-devs On Behalf Of Tom Ellis | Sent: 02 June 2021 11:46 | To: ghc-devs@haskell.org | Subject: Re: value of documenting error messages? | | On Tue, Jun 01, 2021 at 03:40:57PM -0700, Alec

Re: value of documenting error messages?

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

Re: value of documenting error messages?

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 v

Re: value of documenting error messages?

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 mes

Re: value of documenting error messages?

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 availabl

RE: value of documenting error messages?

erg Cc: GHC developers Subject: Re: value of documenting error messages? Hello, If these are the messages that get pretty-printed into errors or warnings, I would think detailed documentation is definitely useful. However, since this is documentation that users of GHC will want to read (and not just co

Re: value of documenting error messages?

Hello, If these are the messages that get pretty-printed into errors or warnings, I would think detailed documentation is definitely useful. However, since this is documentation that users of GHC will want to read (and not just contributors), I think it should live primarily in the user's guide an

value of documenting error messages?

Hi devs, Take a quick look at https://gitlab.haskell.org/ghc/ghc/-/blob/6db8a0f76ec45d47060e28bb303e9eef60bdb16b/compiler/GHC/Driver/Errors/Types.hs#L107 You will see