Wow, thanks! Geoff
On 04/13/2016 07:34 PM, Facundo Domínguez wrote: > 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 <mainl...@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...@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
