Pre-Proposal: Introspective Template Haskell

[Geoffrey Mainland]

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 <mainland at 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