Pre-Proposal: Introspective Template Haskell

[Alan & Kim Zimmerman]

>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 <eric at seidel.io> wrote:

>
>
> 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
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151111/d0e07248/attachment.html>