Hi, On 05/12/2019 10.53, Richard Eisenberg wrote:
Con: - worse error messages, which would now refer to the desugared code instead of the user-written code.
I can think of several major parts that seem useful to solve this. (Please excuse the very abstract and imprecise descriptions.) 1. Most "plugins" will probably still need a way to annotate the AST in some way to inform their error message (i.e. SrcSpan?). These annotations would be expand-only for all other plugins, the type checker, and all other possible transformations. Their only job is to inform their originator about what it did in case of an error. Ideally this would be done in an expandable way. 2. Some stages might want to create suggested ASTs to help the user understand the error, so this option should be part of an error structure bubbling back up through the "plugins". But: the originators of said ASTs should not need to know about annotations other than their own, so they can not be expected to faithfully add them. 3. A "plugin" needs the ability to analyse an erroneous AST inside an error structure and discover how it might have been constructed by said plugin. Crucially, it might want to analyse the suggested ASTs with potentially missing or misleading annotations. This last part has me curious… if a plugin could do that well, it could also quite possibly re-sugar any random piece of AST. In other words there might come a day where GHC can tell a user what their code might look like with different language extensions applied. And that's just the tip of an iceberg of tooling possibilities. So this might be a pipe dream for now. But practically speaking, I expect most programmers to lean in one of two directions: to rely on annotations heavily and ignore any suggested ASTs, or to go all-in on the analysing part and annotate as little as possible. So if even one or two implementers choose this second route, the pipe dream might become a partial reality in the not-so-long term.