Pre-Proposal: Introspective Template Haskell

[Richard Eisenberg]

I've gotten some encouraging feedback here. But I'm worried about the technicalities. I *think* this would all work out, but I'm a little worried about weird recursive dependencies and such. For example, is there something fundamentally important about all the names in THNames being in a package that is not `ghc`? Any thoughts there?

Richard

On Nov 11, 2015, at 11:26 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> Hi devs,
> 
> There's a bunch of open tickets around Template Haskell. A great many of them are attempts to make TH more like what's already in GHC. Of course, when someone improves GHC, then TH also has to be updated. But this doesn't always happen, leading to several of these tickets.
> 
> I believe I have a solution to the problem: just eliminate Template Haskell and provide direct access to GHC's internal structures. The idea (still very sketchy; hence pre-proposal) is like this (numbered for easy reference, but no order is implied):
> 
> 1. TH quotes would remain. DsMeta would desugar quotes into Core code that produces HsExprs. For example, [| 1 |] would have type (Q (LHsExpr Name)). (Or perhaps (Q (LHsExpr RdrName)) if that works out better for clients.)
> 
> 2. TH splices would remain, working much as they do now. The expression inside, say, an expression splice would have type (Q exp) where we can satisfy the constraint (SpliceExpr exp). There would be instances for (SpliceExpr (LHsExpr Name)) and (SpliceExpr (LHsExpr RdrName)) as well as the non-located variants. Generalizing the type of expressions here allows users not to worry about un-renaming when roundtripping between quotes and splices.
> 
> 3. Reification would remain, using an Info structure much like we have now. Would we expose the real GHC TyCons as the result of reification? Or is it better to give the users HsDecls? This would need to be fleshed out.
> 
> 4. Lifting would remain, doing the obvious thing.
> 
> 5. The template-haskell package could even remain, as a backward-compatibility shim. It would declare gobs of pattern synonyms and type synonyms to wrap the new underlying interface. This re-imagined template-haskell package would not need to be a boot library, and could be upgraded separately from GHC. We could even maintain multiple versions of the library so that TH clients wouldn't have to change their code when GHC upgrades. Perhaps someday we could think about deprecating, if that's the way the wind blows.
> 
> So, the end result is a completely re-engineered TH, but I believe we could keep full backward compatibility. (I have not considered Typed TH in any depth yet. But my hope is that it's not too different from the above.) And, we're left with a significantly lower maintenance burden, especially if we eliminate template-haskell someday.
> 
> And, tantalizingly, the flexibility in splices might allow us to splice in *Core* code someday. Perhaps we could also reify Core code. Then clients could write their own custom, domain-aware optimizations. Like RULES on steroids. But that's all for the next phase. (Giving due credit, this last bit is inspired by work David Christiansen is doing in Idris.)
> 
> What's wrong with this idea? I feel like *something* has to be more complicated than I've made it seem!
> 
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs