Pre-Proposal: Introspective Template Haskell

[Eric Seidel]

On Wed, Nov 11, 2015, at 09:50, Richard Eisenberg wrote:
> 
> On Nov 11, 2015, at 12:46 PM, Eric Seidel <eric at seidel.io> 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