<div dir="ltr"><div><div>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.<br><br></div>If the AST is shared, then a scenario of generating TH and being able to pretty-print it in compilable form becomes possible.<br><br></div>Alan<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 11, 2015 at 8:06 PM, Eric Seidel <span dir="ltr"><<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On Wed, Nov 11, 2015, at 09:50, Richard Eisenberg wrote:<br>
><br>
> On Nov 11, 2015, at 12:46 PM, Eric Seidel <<a href="mailto:eric@seidel.io">eric@seidel.io</a>> wrote:<br>
><br>
> > I think backwards-compatibility is still a potential issue, not because<br>
> > the pattern/type synonym layer seems implausible, but because I suspect<br>
> > people will begin to sidestep the compatibility layer and just use the<br>
> > GHC API (I certainly would). GHC is not shy about breaking<br>
> > backwards-compatibility between major releases, so it seems possible<br>
> > that this could extend to breaking TH. Missing features is not nearly as<br>
> > bad as breaking most clients of TH.<br>
><br>
> This is a very good point. We would want to bless some API that would<br>
> remain stable. Then, clients that go around that API get what they<br>
> deserve. A starting point for the stable API would be today's<br>
> template-haskell (less some unsafe features, like exposing NameG).<br>
><br>
> ><br>
> > But perhaps this isn't a very likely scenario. TH mostly exports<br>
> > datatypes for haskell syntax, smart constructors, and a few functions<br>
> > for looking up metadata. I doubt these pieces of GHC change very often,<br>
> > and when they do it's probably an extension rather than a breaking<br>
> > change. Someone with more historical knowledge of GHC could comment :)<br>
><br>
> I actually think this *is* a likely scenario. In the last revision of<br>
> GHC, lots of AST changes have taken place. We would want to insulate TH<br>
> users from this.<br>
<br>
</span>You're talking about the ApiAnnotations stuff right? Or was there<br>
another big change?<br>
<br>
I had assumed that the ApiAnnotations changes fell into the "extension"<br>
category rather than "breaking", because presumably the changes amounted<br>
to adding a bunch of extra record fields (I didn't follow this patch so<br>
could be way off base...)<br>
<br>
Then again, even adding a record field is a breaking change as it<br>
changes the arity of the datacon... So I agree, we really ought to have<br>
a blessed API that we guarantee across versions. We could maintain it<br>
via pattern/type synonyms. (This would be a Good Thing even if we ignore<br>
your proposal!)<br>
<span class="HOEnZb"><font color="#888888"><br>
Eric<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>