Re: Reification of out-of-scope variables?

I don't have a better idea. I've added a few small comments to the bottom of that wiki page, which still, for me, represents the best solution to this problem. Richard On Apr 18, 2016, at 5:01 PM, "Boespflug, Mathieu" wrote: > Hi all, > > For our use case, namely automatic

Re: Reification of out-of-scope variables?

Hi all, For our use case, namely automatic bindings generation via quasiquotation à la language-c-inline, typed quasiquotation alone wouldn't solve much. Because in order to be sensible it would likely have to be restricted (one way or another) to only allowing reification of variables in the

Re: Reification of out-of-scope variables?

On Apr 15, 2016, at 11:51 AM, Simon Peyton Jones wrote: > > Hang on! The design for typed splices, describe here, > https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges > says "Unlike TH, the only way to construct a value of type TExp is with a > quote.

RE: Reification of out-of-scope variables?

| > * 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.

RE: Reification of out-of-scope variables?

| a TExp rather than an Exp. Turns out the example from my first email | does work if you adapt it to use typed splices: | | f :: Int -> Int | f x = $$(do let {name = mkName x}; info <- reify name; runIO (print | info) [|| x ||]) Hang on! The design for typed splices, describe here,

Re: Reification of out-of-scope variables?

Michael, Please, feel free to add your thoughts to the wiki. I couldn't follow your proposal in enough detail to make it justice. Facundo On Wed, Apr 13, 2016 at 8:34 PM, Facundo Domínguez wrote: > Here is the wiki page [1] and here is the ticket [2] > > Best > >

Re: Reification of out-of-scope variables?

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 wrote: > I'm afraid I'm coming late to the game,

Re: Reification of out-of-scope variables?

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

Re: Reification of out-of-scope variables?

This is a bit invasive, but I don't immediately see an easier way. I'd personally want a few more people to weigh in before accepting this plan of attack. In your favor is that you are Real Users who want the feature to Get Work Done. Let's see what others think, but I'm not opposed. Richard

Re: Reification of out-of-scope variables?

Very interesting. On Apr 13, 2016, at 5:09 AM, "Boespflug, Mathieu" 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.

Re: Reification of out-of-scope variables?

An implementation for untyped splices could be: * Have a map from internal names to the local typing environments. * When the renamer runs addGroupFinalizer it generates an internal name and annotates the AST with the internal name at the location of the splice. * When the type checker finds the

Re: Reification of out-of-scope variables?

Hi Richard, Facundo and I had a chat about this offline. Facundo noticed that there /is/ a form of splicing that runs during type checking, and therefore has access to the type environment: namely typed splices, which return a TExp rather than an Exp. Turns out the example from my first email

Re: Reification of out-of-scope variables?

On Apr 12, 2016, at 5:35 PM, Facundo Domínguez 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

Re: Reification of out-of-scope variables?

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

Re: Reification of out-of-scope variables?

I actually don't think this would be all that hard to do. Concretely, how would this work: TH will offer a new function `addGroupFinalizer :: Q () -> Q ()` that runs its argument in the local typing environment available when addGroupFinalizer is called. However, by the time the passed action

Re: Reification of out-of-scope variables?

I have considered how to add this capability some in the past, it's something I'd also like to have. Collecting the type info in the module finalizer is an interesting idea! This may well be the cheapest way to get the info necessary for this usecase. As far as I understand it, currently we're

Reification of out-of-scope variables?

Hi all, the community is increasingly using quasiquotation as a means to interoperate with foreign languages. E.g. language-c-inline, inline-c and inline-r allow calling foreign functions using foreign language syntax, rather than "foreign import" declarations. There are efforts underway for