On Nov 11, 2015, at 12:46 PM, Eric Seidel <[email protected]> wrote: > I think backwards-compatibility is still a potential issue, not because > the pattern/type synonym layer seems implausible, but because I suspect > people will begin to sidestep the compatibility layer and just use the > GHC API (I certainly would). GHC is not shy about breaking > backwards-compatibility between major releases, so it seems possible > that this could extend to breaking TH. Missing features is not nearly as > bad as breaking most clients of TH.
This is a very good point. We would want to bless some API that would remain stable. Then, clients that go around that API get what they deserve. A starting point for the stable API would be today's template-haskell (less some unsafe features, like exposing NameG). > > But perhaps this isn't a very likely scenario. TH mostly exports > datatypes for haskell syntax, smart constructors, and a few functions > for looking up metadata. I doubt these pieces of GHC change very often, > and when they do it's probably an extension rather than a breaking > change. Someone with more historical knowledge of GHC could comment :) I actually think this *is* a likely scenario. In the last revision of GHC, lots of AST changes have taken place. We would want to insulate TH users from this. Richard > > All in all, I like this idea a lot! > > Eric > > On Wed, Nov 11, 2015, at 08:26, 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 > _______________________________________________ > 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
