I've marked this as easy, meaning it should only require basic Haskell knowledge and a working knowledge of aeson, not because it will be a quick change.

This would be great, it's a pain to parse the current variable number of lines. As well as obviously line/column numbers, module/filename it would be really good to be able to have a short "headline" 1-line error message as well as the multiple line "explanatory" version

I'll start writing some instances this evening :)

What about moving this to 0.8, since it is in the error-messages bucket?

Moving to 0.8, I think this could be really useful.

@kritzcreek @nwolverson Is there anything else you would like to have available in the JSON document?

• Line and column numbers
• Module name and file path
• Short error message
• Full error message
• Link to the appropriate wiki page

I was going to try to keep things pretty simple, and just have a handful of fields like this, keeping the error message text formatted as it is now, but if you think there is benefit to breaking up the error message parts further (for example, for formatting in an IDE), let me know.

For suggestions: Hints, as patches / diffs. 😄

Actually, that'd be nice in the non-JSON errors / warnings, too.

I like that idea, and it's easier to implement than trying to point at the offending location in ascii art 😄 I'll write it up.

Having some kind of pretty printer to turn the AST into code would be nice for more advanced refactoring (extract/inline method, etc...) aswell so I'm all in for the patch/diff thingy.

One more field that would be nice is some "tag" that denotes the kind of error like "CantUnifyTypes", "UndefinedIdentifier"... I want to respond to errors which could correspond to mistyping with suggestions based on edit-distance.

We could of course shift that into the compiler so that we could provide it in the human readable errors aswell.

Severity (not sure if that's just error/warning or if we potentially have others later).

My view is that you have all the metadata an IDE/plugin needs, plus the full "compiler knows best" output which could be visible on request and would be in a "build log" type view.