#8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13122 Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): alanz, indeed much of the motivation for providing these annotations to begin with is to enable tooling like Idris'. mpickering, your assessment is pretty much dead on. I agree that we can and should move ahead with (1) independently from (2). `ErrMsg` already includes the information that we would need to do this; all that needs to be done is to ensure that we don't lose it and potentially add some output format for tooling consumers (e.g. JSON). However, I think we should refrain from trying to solve the weakened form of (2) that comment:52 tackles. This approach appears to introduce a lot of accidental complexity for what is easily accomplished using an existing annotated pretty-printing library. The only thing holding us back from moving ahead here is #10735. As far as I can tell, the problem in #10735 is that both the [[https://github.com/ekmett/wl-pprint-extras/issues/16|Wadler-Leijen]] and [[https://github.com/haskell/pretty/issues/32|Hughes]] pretty-printers can become quadratic in some cases. This hurts a great deal in the case of GHC, where we use the pretty-printer to emit massive quantities of code. Mpickering has advocated that we work around the issue by simply eliminating the use of the pretty-printer for code generation. I would prefer that we not do this if possible. Ultimately I believe that the root cause of the non-linearity is back-tracking due to the document exceeding the ribbon width. However, when we are producing code we configure `pretty` with an infinite ribbon width, meaning that it should never be necessary to backtrack. Unfortunately the `pretty` implementation doesn't take advantage of this fact. I argue that this should be fixed. The other related issue is the inability to make use of `FastString` with the upstream `pretty` since the `text` combinator has type `String -> Doc`. This is actually a very poor interface as `text` needs the length of the string, which is an O(n) operation. Really it should at least allow usage of a more efficient string representation. niteria and I discussed this a few months ago and agreed that this could be resolved by simply generalizing `text` over its string type with a typeclass providing an `unpack` and `length` function. goldfire, does any of the above sound like a reasonable task for your student? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8809#comment:60 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler