Yes, that's right. But with a compatibility shim, no longer tied into GHC, that could provide stability and/or a simpler interface. This compatibility shim would likely be called template-haskell. (I retract the idea of deprecating the package. But we could democratize its maintenance rather easily after this change.)
Richard On Nov 12, 2015, at 12:12 PM, Geoffrey Mainland <mainl...@apeiron.net> wrote: > Hi Richard, > > Please correct me if I misunderstand, but in summary, you propose to > change Template Haskell so that GHC's internal AST is produced directly, > instead of the current route where there is an intermediate TH AST? > > Geoff > > On 11/11/2015 11:26 AM, Richard Eisenberg 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@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
