>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 <e...@seidel.io> wrote: > > > On Wed, Nov 11, 2015, at 09:50, Richard Eisenberg wrote: > > > > On Nov 11, 2015, at 12:46 PM, Eric Seidel <e...@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 > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
