This proposal now has a home at wiki:TemplateHaskell/Introspective and #11081.
I think exploring how this might help haskell-src-exts would be very fruitful. Richard On Nov 13, 2015, at 4:18 PM, Geoffrey Mainland <[email protected]> wrote: > 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 <[email protected]> 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 [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
