
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