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