[GHC] #8809: Prettier error messages?

GHC ghc-devs at haskell.org
Sat Jan 14 21:25:12 UTC 2017


#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 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.

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


More information about the ghc-tickets mailing list