re-engineering overloading and rebindable syntax

[Simon Peyton Jones]

Sounds attractive.  By all means open a ticket, giving details.  I'm hazy about those details.  I think you are implying that every single piece of rebindable syntax can be typechecked by instead typechecking some (invisible) function application. Including when you are not using rebindable syntax: just use a built-in function.  

I think that's the way rebindable syntax mostly works today, but I'm not 100% sure that the vanilla (no -XRebindableSyntax) case is always done that way.   One way to get at this would be to write a table of all the cases where rebindable syntax is used, and what the equivalent function application or typing judgement is.  That would be helpful regardless!

Examples of where the error message gets worse, and why, would help to focus the conversation.

Simon 

|  -----Original Message-----
|  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Richard
|  Eisenberg
|  Sent: 05 December 2019 09:54
|  To: Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org>
|  Subject: re-engineering overloading and rebindable syntax
|  
|  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
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs