[GHC] #8809: Prettier error messages?

[GHC]

#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:
 Related Tickets:                    |  Differential Rev(s):
  #8809,#10073,#10179,#12906         |
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by mpickering):

 Replying to [comment:48 bgamari]:
 > mpickering, I agree that the issue of semantics messages should be moved
 to another ticket. Richard, perhaps you could have your student do this
 when the semester starts up?
 >
 > > The solution here seems to be to use a different (simpler) pretty
 printing library for code generation as this shouldn't require complicated
 layout instructions such as hanging or nesting.
 >
 > As I've expressed in the past, I'm not at all sure that the solution to
 #10735 is to invent another pretty-printer. As far as I know there is no
 reason why the semantics implemented by `pretty` can't be implemented with
 the exact same computation effort as a simpler printer in the case of
 infinite ribbon width. I know that I have found the ability to spit out
 `SDoc`s in assembler output to be quite useful in the past and I would
 hate to lose it, especially if doing so meant introducing a redundant
 pretty-printing implementation which could be avoided with a bit of
 refactoring.
 >
 > Of course, if I'm wrong and there is a fundamental reason why `pretty`
 incurs an unavoidable overhead then I'm happy to concede this point.

 To put this in context, no one is still sure where the problem in `pretty`
 lies and this isn't for lack of trying. At least @thomie, @erikd and
 @niteria (three very fine hackers) have tried to find out where the
 problems are but haven't managed to find a fix. We don't want to move
 ahead with this until #10735 is resolved as doing so would cause `pretty`
 to diverge even further.

 This being said, I consider this ticket a high priority for 8.4 as it
 finally will provide better support for tooling. This is why I don't want
 it to be blocked on a very difficult ticket when there is a simple albeit
 suboptimal solution on the table. The benefit of implementing this
 outweighs the cost of the loss of convenience in the code generation in my
 opinion.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8809#comment:50>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler