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 <[email protected]> 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" <[email protected]> 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 <[email protected]> wrote: >>>> On Apr 12, 2016, at 5:35 PM, Facundo Domínguez >>>> <[email protected]> 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 >>>> > _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
