Reification of out-of-scope variables?

[Facundo Domínguez]

Here is the wiki page [1] and here is the ticket [2]

Best

[1] https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Reify
[2] https://ghc.haskell.org/trac/ghc/ticket/11832

On Wed, Apr 13, 2016 at 5:37 PM, Geoffrey Mainland <mainland at drexel.edu> wrote:
> I'm afraid I'm coming late to the game, so I'm not clear on the extent
> of the problem (or even precisely what it is that isn't working).
>
> In addition to creating a ticket, it would be great to have a wiki page
> that outlines the problem and proposed solution(s).
>
> The TH finalizer stuff was meant to make support for things like
> language-c-inline easier, but it is incomplete. Before we go munging
> around again, it would be good to have a list of use cases so we can
> cover all the bases this time.
>
> Geoff
>
> On 04/13/2016 04:25 PM, Richard Eisenberg wrote:
>> Very interesting.
>>
>> On Apr 13, 2016, at 5:09 AM, "Boespflug, Mathieu" <m at tweag.io> wrote:
>>> * Should we consider it a bug (and file a ticket) that reification in
>>> typed splices is able to observe the order of type checking, just like
>>> reify used to do in untyped splices?
>> I think so, yes.
>>
>>> * While Richard's proposed addGroupFinalizer might not work with
>>> untyped splices, perhaps it can be made to work with typed splices,
>>> since these run in the type checker?
>> I think so, yes. Perhaps it would be more well-typed to have typed TH splices run in a new monad TQ such that TQ allows addGroupFinalizer but Q does not. This may be overkill though.
>>
>>> * If part of the solution here is to use typed splices, how do we get
>>> quasiquotation to be syntactic sugar for a *typed* splice? Do we want
>>> to be introducing a typed quasiquotation syntax, just like Geoff did
>>> for much of the rest of Template Haskell?
>> Maybe. Quasiquotation sugar is very light: [blah|...|] is the same as $(selector blah "...") where `selector` is the right record selector depending on the splice context. Is it worth trying to expand quasiquotation syntax to work with typed TH? I'm unconvinced it's worth the bother. Also, note that doing [blah||...||] is not backward-compatible, because that looks like an untyped quasiquote that begins and ends with a vertical bar. We could get around this problem by using a new extension, but the waters are just getting muddier, and for seemingly little benefit.
>>
>> Richard
>>
>>> Facundo and I think that something like Richard's addGroupFinalizer is
>>> still interesting to have, because while reification during type
>>> checking sounds dubious, reification /after/ the declaration group is
>>> fully type checked is perfectly safe.
>>>
>>> Best,
>>> --
>>> Mathieu Boespflug
>>> Founder at http://tweag.io.
>>>
>>>
>>> On 13 April 2016 at 04:25, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>>>> On Apr 12, 2016, at 5:35 PM, Facundo Domínguez <facundo.dominguez at tweag.io> wrote:
>>>>
>>>>> Hello Richard,
>>>>>
>>>>>> TH will offer a new function `addGroupFinalizer :: Q () -> Q ()` that runs its argument in the local typing environment available when addGroupFinalizer is called.
>>>>> When considering this approach, how could one capture the local typing
>>>>> environment given that the untyped splices are run in the renamer
>>>>> where no such environment is populated yet?
>>>>>
>>>> Ah. Excellent point. I hadn't quite thought it through. Not sure, off the top of my head, how to get around this.
>>>>
>>>> Richard
>>>>
>