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
#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]: 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