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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
ld not repeat (A); rather it should assume you are also looking at (A) for
that error number, and add any implementation specific info, like what the
fields mean, and what the test cases are.
Simon
From: ghc-devs On Behalf Of Alec Theriault
Sent: 01 June 2021 23:41
To: Richard Eisenb
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
16 matches
Mail list logo
