re-engineering overloading and rebindable syntax

[Richard Eisenberg]

Hi devs,

I've recently discovered the `overloaded` package, which allows us to do very clever things around overloading in a source plugin. In my over-excitement, I wondered about removing GHC's capability to do overloading and rebindable syntax, leaving those features to be implemented by source plugins. To first approximation, this would work well. But there are many drawbacks: poorer error messages, worries around the trustworthiness of non-GHC source plugins, cross compilation, etc. The idea is not viable right now.

Yet: I wonder if we couldn't take the general idea of doing this as source plugins, without actually implementing it that way. Currently, there is a good deal of code scattered throughout GHC to deal with overloaded constructs (numbers, strings, lists) and rebindable syntax. These make their presence known in a number of places in HsExpr and friends, and various machinations in the renamer and type-checker are needed to deal with them. The type-checker for rebindable syntax is buggy (#14963 and friends); the fix will involve likely *more* code devoted to rebindable syntax (albeit simpler code than what we have today).

If, say, the renamer implemented all overloading and rebindable syntax just by a straightforward syntactic transformation, this would all be much simpler. (Actually, it could also be done in the parser, but I think the renamer is a better home.)

Pros:
 - much, much simpler implementation
 - localized implementation: nothing in the type checker at all nor in HsSyn

Con:
 - worse error messages, which would now refer to the desugared code instead of the user-written code.

I can't think of any other downside.

How can we mitigate this? By expanding the possibilities of a SrcSpan. A SrcSpan is really a description of the provenance of a piece of AST. Right now, it considers two possibilities: that the code came from a specific stretch of rows and columns in an input file, or that the code came from elsewhere. Instead, we can expand (and perhaps rename) SrcSpan to include more possibilities. In support of my idea above, we could now have a SrcSpan that says some AST came from overloading. Such code is suppressed by default when pretty-printing. Thus, `fromString "blah"` could render as just `"blah"` (what the user wrote), if fromString was inserted by the translation pass described above. We can have a separate new SrcSpan that says that AST was written by translation from some original AST. That way, `ifThenElse a b c` can be printed as `if a then b else c`, if the former were translated from the latter. Though it's beyond my use-case above, we can also imagine a new SrcSpans that refer to a Template Haskell splice or a quasiquote.

What do we think? Is this a worthwhile direction of travel? I think the end result would be both a cleaner implementation of overloading and rebindable syntax *and* more informative and useful source-code provenances.

Richard