re-engineering overloading and rebindable syntax

[MarLinn]

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.