Sounds like a good pan to me. Note that we would still need a small GHC-version-specific shim, somewhere, to define the Q monad, which does occasionally change. We could push it into the GHC API.
Having three Haskell ASTs has always been a pain---it would be nice to finally fix this situation. Using your proposal, we could implement a fully compatible template-haskell library on top of the GHC AST and the "internal" Q monad. We could also implement an analogous package that was based on haskell-src-exts instead; in fact, it would be nice if the latter became the "standard" Template Haskell implementation, as it would also help us avoid hacks like haskell-src-meta. Geoff On 11/12/15 9:14 AM, Richard Eisenberg wrote: > 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
