On Wed, Nov 11, 2015, at 09:50, Richard Eisenberg wrote: > > On Nov 11, 2015, at 12:46 PM, Eric Seidel <[email protected]> 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 [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
