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...@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 <e...@cis.upenn.edu> wrote: >>> On Apr 12, 2016, at 5:35 PM, Facundo Domínguez <facundo.doming...@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 >>> _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
