Closed alpmestan closed 4 years ago
@goldfirere In light of your reaction to the open error types hierarchy, I switched to the closed, simpler one. I thought the several .hs-boot
files would be frowned upon a lot more than that, and Ben considers this less of an annoyance than he used to, in light of all the discussions we've had so far.
Feedback welcome!
For the sake of minimalism, I think it's best to leave the error codes out of this proposal. But I definitely love the idea, and it would be pretty straightforward to implement, once the categories are figured out. It's precisely because of the potential for bikeshedding around the bins that I suggest that we leave them out.
I can definitely mention them though, as a rather straightforward extension of this proposal. The educational value of such an "error manual" would be massive.
OK. I see the value of minimalism here: this proposal is only an internal refactoring, with nothing visible to users. That's a very nice property and one worth maintaining.
@goldfirere I did my best to address your feedback in the latest commit. The error code idea is now mentioned in the "Effects and interactions" section, I clarified that the cost of implementing this proposal is mostly a short-term one and fixed the type signature of errorMessage
.
Let me know what you think. :-)
I think this is ready for public consumption. I'm sure there will be more to improve, but l think it's ready to post to ghc-proposals. Thanks!
@goldfirere It's now up, at https://github.com/ghc-proposals/ghc-proposals/pull/306
@bgamari @goldfirere Here's a first shot at a proposal for representing errors as values of good old ADTs, the first part of the plan to get where we want.
(The second will be a proposal for enriching the document representations ,
Doc
andSDoc
. The errors would then be able to take advantage of this by emitting documents that contain expressions/types/etc as annotations, therefore reaching our goal.)