Re: Pre-Proposal: Introspective Template Haskell

Sounds like a good pan to me. Note that we would still need a small GHC-version-specific shim, somewhere, to define the Q monad, which does occasionally change. We could push it into the GHC API. Having three Haskell ASTs has always been a pain---it would be nice to finally fix this situation.

Re: Pre-Proposal: Introspective Template Haskell

This proposal now has a home at wiki:TemplateHaskell/Introspective and #11081. I think exploring how this might help haskell-src-exts would be very fruitful. Richard On Nov 13, 2015, at 4:18 PM, Geoffrey Mainland wrote: > Sounds like a good pan to me. Note that we would

Re: Pre-Proposal: Introspective Template Haskell

Yes, that's right. But with a compatibility shim, no longer tied into GHC, that could provide stability and/or a simpler interface. This compatibility shim would likely be called template-haskell. (I retract the idea of deprecating the package. But we could democratize its maintenance rather

Re: Pre-Proposal: Introspective Template Haskell

Hi Richard, Please correct me if I misunderstand, but in summary, you propose to change Template Haskell so that GHC's internal AST is produced directly, instead of the current route where there is an intermediate TH AST? Geoff On 11/11/2015 11:26 AM, Richard Eisenberg wrote: > Hi devs, > >

Re: Pre-Proposal: Introspective Template Haskell

On Nov 11, 2015, at 12:46 PM, Eric Seidel wrote: > I think backwards-compatibility is still a potential issue, not because > the pattern/type synonym layer seems implausible, but because I suspect > people will begin to sidestep the compatibility layer and just use the > GHC API

Re: Pre-Proposal: Introspective Template Haskell

>From an ApiAnnotations point of view, they will change to match changes in the AST, they cannot be a brake on improvements. We do intend to nudge the AST toward being more ApiAnnotations friendly over time. If the AST is shared, then a scenario of generating TH and being able to pretty-print it

Re: Pre-Proposal: Introspective Template Haskell

I think backwards-compatibility is still a potential issue, not because the pattern/type synonym layer seems implausible, but because I suspect people will begin to sidestep the compatibility layer and just use the GHC API (I certainly would). GHC is not shy about breaking backwards-compatibility

Re: Pre-Proposal: Introspective Template Haskell

On Wed, Nov 11, 2015, at 09:50, Richard Eisenberg wrote: > > On Nov 11, 2015, at 12:46 PM, Eric Seidel wrote: > > > I think backwards-compatibility is still a potential issue, not because > > the pattern/type synonym layer seems implausible, but because I suspect > > people

Pre-Proposal: Introspective Template Haskell

Hi devs, There's a bunch of open tickets around Template Haskell. A great many of them are attempts to make TH more like what's already in GHC. Of course, when someone improves GHC, then TH also has to be updated. But this doesn't always happen, leading to several of these tickets. I believe

Re: Pre-Proposal: Introspective Template Haskell

In practice I find that almost every piece of template-haskell code I've written gets broken by something every other release of GHC, so it hasn't exactly been a shining beacon of backwards compatibility thus far. Invariably it is always missing _something_ that I need, and anything that ties it

Re: Pre-Proposal: Introspective Template Haskell

On Nov 11, 2015, at 2:25 PM, Edward Kmett wrote: > > As a data point, in a couple of packages I wind up forced into using > mkNameG_v and mkNameG_tc in order to avoid incurring a dependency on a stage2 > compiler today. Removing them would force me to drop support for

Re: Pre-Proposal: Introspective Template Haskell

That would be a sufficient "horrible backdoor" for me. :) -Edward > On Nov 11, 2015, at 3:03 PM, Richard Eisenberg wrote: > > >> On Nov 11, 2015, at 2:25 PM, Edward Kmett wrote: >> >> As a data point, in a couple of packages I wind up forced into using

Re: Pre-Proposal: Introspective Template Haskell

On Wed, Nov 11, 2015 at 12:50 PM, Richard Eisenberg wrote: > > This is a very good point. We would want to bless some API that would > remain stable. Then, clients that go around that API get what they deserve. > A starting point for the stable API would be today's

Re: Pre-Proposal: Introspective Template Haskell

If I understand this correctly it would also subsume haskell-src-exts. If so I would definitely support this. On Nov 11, 2015 2:21 PM, "Edward Kmett" wrote: > In practice I find that almost every piece of template-haskell code I've > written gets broken by something every other

Re: Pre-Proposal: Introspective Template Haskell

Well, as of 7.10.2 the GHC AST no longer has bottoms in it, so it can already be used quite easily On Wed, Nov 11, 2015 at 9:53 PM, Thomas Bereknyei wrote: > If I understand this correctly it would also subsume haskell-src-exts. If > so I would definitely support this. > On

Re: Pre-Proposal: Introspective Template Haskell

I've gotten some encouraging feedback here. But I'm worried about the technicalities. I *think* this would all work out, but I'm a little worried about weird recursive dependencies and such. For example, is there something fundamentally important about all the names in THNames being in a