Opened 4 years ago

Last modified 4 years ago

#10331 new feature request

Accept HsSyn in splices and generate it in quotes (ghc-api)

Reported by: ezyang Owned by:
Priority: low Milestone:
Component: Template Haskell Version: 7.11
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

I propose a language pragma GhcTemplateHaskell, which, when enabled, causes Template Haskell splices to accept HsSyn return values, and causes TH quotes to return HsSyn trees. Users of GhcTemplateHaskell would stop using the template-haskell library and just directly manipulate the frontend ASTs using the ghc-api.

Given our ghc-api track record, you would probably not be able to write code using this without having it break every GHC release. However, clients who are willing to track GHC development would reap the following benefits:

  1. All syntax in Haskell would be supported in quotes; the AST would never lag behind. Additionally, you could use the ghc-api parser to parse Haskell code to be returned in a splice. (#2041)
  1. Locations from quoting would be preserved. (Problem 2 of #10330)

I don't think this would be difficult to implement, but it definitely could be a ball of wax. I broke this proposal off from #2041.

Change History (3)

comment:1 Changed 4 years ago by goldfire

I propose a slightly different direction: parameterize TH over the choice of AST. Something like

class ExpAST e where
  repExp :: LHsExpr Name -> DsM (Core (TH.Q e))
  cvExp  :: e -> CvtM (LHsExpr RdrName)

Then, we define instances ExpAST (LHsExpr Name) and ExpAST TH.Exp. Perhaps the haskell-src-exts folks can define their own instance, too, if they so choose.

I haven't thought this through, so apologies if this is a terrible idea.

While we're moving in this direction, it might be nice to expose TcM to clients of TH. I know various terrible things could be done with the power of TcM, but nice things can, too.

(In particular, I've wanted to be able to expand closed type families from TH code. I've implemented that functionality once [in GHC], and I dearly don't want to do it again! Exposing TcM would allow me to start thinking about how to do this.)

comment:2 Changed 4 years ago by simonpj

I'm utterly lost. To understand what is proposed here I need a lot more specifics and examples. For example

  • I think (though you do not say) that clients of the language extension would abandon all use of the template-haskell library. Instead they would depend on the ghc library.
  • I think that [| e |] would have type Q (HsExpr RdrName).

Etc etc. But it needs fleshing out or we'll all just talk at cross purposes.

comment:3 Changed 4 years ago by goldfire

Yes, agreed about the fleshing out... but I don't have the bandwidth to get deeply involved in this upgrade to TH at the moment. I was just offering the idea of parameterizing via classes instead of making a monolithic change. I think the ExpAST thing would be no more work than the monolithic change originally proposed, but would be more flexible with little cost.

That said, someone who actually wants to devote time into this is quite welcome to ignore my suggestion.

Note: See TracTickets for help on using tickets.