#8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: | TypeErrorMessages 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,#13670 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by cdsmith): I'm summarizing a conversation with Richard in the hallway at ICFP. What would be nice is basically a separation of the logic to detect and gather information about an error from the logic to build an error message. I think this can be done with a reasonable migration path. I'm assuming a vanilla heterogeneous typed map, of a type that I'm sure exists many times over in Hackage. Details here could differ, but aren't all that relevant. {{{ #!haskell data TypedMap type TypedKey v = (String, Proxy v) empty :: TypedMap get :: TypedMap -> TypedKey v -> Maybe v put :: TypedKey v -> v -> TypedMap -> TypedMap }}} The key to a quick transition is to store the existing error messages (an `SDoc`, is that right?) alongside the map with more information. Then an error message is just a `(SDoc, TypedMap)`. As a starting point, existing code to report errors can just use an empty map, and the initial error message formatting can ignore the map and just show the message. So initial refactoring would have no effect. As a second step, one could add further stages on the formatting side that match a subset of errors (or even combinations of errors) and emit custom error messages. To make these useful, the map would often be extended with extra information at the reporting site. This would usually include at least some unique name or code indicating the kind of error this is, and optional keys that could point to expressions, types, etc. What this does is create a single place for logic that recognizes error patterns that occur frequently because of common mistakes, and does something smart with them. One could imagine this being another plugin point, where plugins could make improvement passes to the set of errors. These plugins might do very non-trivial things, such as trying to reparse a failed module with a whole new grammar that identifies common errors. This is a little weaker than the naive approach of defining a gigantic algebraic data type of all errors, as that sounds like a maintenance nightmare. It also keeps basic error messages in place so that work is only needed on the formatter side if and when a specific error is targeted for improvement. Just an initial thought. It seems to be mostly independent of the choice of how to pretty-print the message output (e.g., embedding rich types to be communicated to an IDE). This is about deciding what to say to the user in the first place. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8809#comment:80 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler