Rust has taken an interesting approach for this: every error message is given a unique number like "E0119" and there is an error index<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.rust-lang.org%2Ferror-index.html%23E0119&data=04%7C01%7Csimonpj%40microsoft.com%7C15e3afdfef1346a3e27a08d9254e7c63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637581843865456276%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fNrQBjAVF2CrG5tCZYTGg0DVIOxRszYNp49ixg%2F4%2FX0%3D&reserved=0> generated from simple markdown files<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frust-lang%2Frust%2Ftree%2Fmaster%2Fcompiler%2Frustc_error_codes%2Fsrc%2Ferror_codes&data=04%7C01%7Csimonpj%40microsoft.com%7C15e3afdfef1346a3e27a08d9254e7c63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637581843865466273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=m6m4y%2BbabeAbLf0X7l%2FYGRo7qvqYQu1W0onZ8k7uBYI%3D&reserved=0> containing explanations and examples for the errors (error codes by themselves already massively help searchability). If GHC were to take this approach, I think it would be fine to just include the error message identifier in the Haddocks.
I think this is a great idea, including that of giving unique numbers. We should be aware that there are two client groups: 1. Users, for whom the error index above is ideal 2. Clients of the GHC API (e.g. authors of an IDE) who are consuming the data type itself, and need to know what the various fields mean. For (A) the Rust approach seems terrific. For (B) adding Haddocks as in the example Richard gave seems better. But it should 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 <ghc-devs-boun...@haskell.org> On Behalf Of Alec Theriault Sent: 01 June 2021 23:41 To: Richard Eisenberg <r...@richarde.dev> Cc: GHC developers <ghc-devs@haskell.org> 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 contributors), I think it should live primarily in the user's guide and not the Haddocks. Rust has taken an interesting approach for this: every error message is given a unique number like "E0119" and there is an error index<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.rust-lang.org%2Ferror-index.html%23E0119&data=04%7C01%7Csimonpj%40microsoft.com%7C15e3afdfef1346a3e27a08d9254e7c63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637581843865456276%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fNrQBjAVF2CrG5tCZYTGg0DVIOxRszYNp49ixg%2F4%2FX0%3D&reserved=0> generated from simple markdown files<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frust-lang%2Frust%2Ftree%2Fmaster%2Fcompiler%2Frustc_error_codes%2Fsrc%2Ferror_codes&data=04%7C01%7Csimonpj%40microsoft.com%7C15e3afdfef1346a3e27a08d9254e7c63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637581843865466273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=m6m4y%2BbabeAbLf0X7l%2FYGRo7qvqYQu1W0onZ8k7uBYI%3D&reserved=0> containing explanations and examples for the errors (error codes by themselves already massively help searchability). If GHC were to take this approach, I think it would be fine to just include the error message identifier in the Haddocks. Alec PS: Rust even bundles the documentation for errors into the compiler, so you can do something like `rustc --explain E0119` to get the full description of the error. It'd be pretty neat if GHC could do this too. Some errors don't have much to say about them, but others definitely could be explained! On Tue, Jun 1, 2021 at 2:36 PM Richard Eisenberg <r...@richarde.dev<mailto:r...@richarde.dev>> wrote: Hi devs, Take a quick look at https://gitlab.haskell.org/ghc/ghc/-/blob/6db8a0f76ec45d47060e28bb303e9eef60bdb16b/compiler/GHC/Driver/Errors/Types.hs#L107<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fblob%2F6db8a0f76ec45d47060e28bb303e9eef60bdb16b%2Fcompiler%2FGHC%2FDriver%2FErrors%2FTypes.hs%23L107&data=04%7C01%7Csimonpj%40microsoft.com%7C15e3afdfef1346a3e27a08d9254e7c63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637581843865466273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=kXIh0I3JZObTbB8Huki5EHFaPGHNcjcYBKxpBpfeqNM%3D&reserved=0> You will see a datatype there with constructors describing error messages that GHC might produce. These constructors have comments describing the error, sometimes giving an example, and sometimes listing test cases. More datatypes like this one and more constructors in these datatypes are on the way. Question: Is there sufficient value in carefully documenting each constructor? In my ideal world, each constructor would have a high-level description, a detailed description of each field, an example of a program that generates the error, and one or more test cases that test the output. Along the way, we might discover that no such test case exists, and then we would add. However, generating this documentation is hard. I was thinking of whipping up an army of volunteers (Hécate has advised me how to do this) to do the work, but that army will need to be fed (with instructions, supervision, and reviews) and will want to know that their work is important. Is this effort worthwhile? Do we see ourselves maintaining this documentation? Or is the effort better spent elsewhere, perhaps tagging each constructor with an ID and then making wiki pages? Not sure what's best -- would love ideas! Credit to Alfredo di Napoli, who's done the heavy lifting of getting us this far. Relevant tickets: Original: https://gitlab.haskell.org/ghc/ghc/-/issues/18516<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F18516&data=04%7C01%7Csimonpj%40microsoft.com%7C15e3afdfef1346a3e27a08d9254e7c63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637581843865476267%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xy2lUIjOwAtV%2BjZajPytLyyiy3f94xIulkTt8tHAF5g%3D&reserved=0> Tasks left: https://gitlab.haskell.org/ghc/ghc/-/issues/19905<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F19905&data=04%7C01%7Csimonpj%40microsoft.com%7C15e3afdfef1346a3e27a08d9254e7c63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637581843865476267%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mJHN1JSv5lvCdByhLpwzGwgnGOCKGY7Oej2UbYvFttI%3D&reserved=0> Thanks, Richard _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=04%7C01%7Csimonpj%40microsoft.com%7C15e3afdfef1346a3e27a08d9254e7c63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637581843865486259%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3dZA9c6ZPotW0A89KIvEVyuXkB0tfRJVU6uUGVgZwik%3D&reserved=0>
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
