Re: re-engineering overloading and rebindable syntax

I find this idea attractive. Could we desugar `do` in the same manner using this SrcSpan trick? Could we desugar infix operators `a + b` to `(+) a b`? We just need to store in theh SrcSpan that the (+) was actually infix. Implementing as much syntactic sugar as possible this way would let us push complexity out of the type checker. - Vlad

On 5 Dec 2019, at 12:53, Richard Eisenberg wrote:

Hi devs,

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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs