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 in compilable form becomes possible. Alan On Wed, Nov 11, 2015 at 8:06 PM, Eric Seidel wrote:

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 will begin to sidestep the compatibility layer and just use the GHC API (I certainly would). GHC is not shy about breaking backwards-compatibility between major releases, so it seems possible that this could extend to breaking TH. Missing features is not nearly

as

...

...

bad as breaking most clients of TH.

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 template-haskell (less some unsafe features, like exposing NameG).

...

But perhaps this isn't a very likely scenario. TH mostly exports datatypes for haskell syntax, smart constructors, and a few functions for looking up metadata. I doubt these pieces of GHC change very often, and when they do it's probably an extension rather than a breaking change. Someone with more historical knowledge of GHC could comment :)

I actually think this *is* a likely scenario. In the last revision of GHC, lots of AST changes have taken place. We would want to insulate TH users from this.

You're talking about the ApiAnnotations stuff right? Or was there another big change?

I had assumed that the ApiAnnotations changes fell into the "extension" category rather than "breaking", because presumably the changes amounted to adding a bunch of extra record fields (I didn't follow this patch so could be way off base...)

Then again, even adding a record field is a breaking change as it changes the arity of the datacon... So I agree, we really ought to have a blessed API that we guarantee across versions. We could maintain it via pattern/type synonyms. (This would be a Good Thing even if we ignore your proposal!)

Eric _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs