I don't know about the entire AST. GHC's AST contains a lot of complexity that one wouldn't want to expose at the TH level. And the separation allows GHC to change the internal AST around while maintaining a stable interface for packages depending on TH.
That said, there are some bits that I could see being shared. Fixity and Strict from TH come to mind. On Wed, Sep 2, 2015, 11:39 Alan & Kim Zimmerman <[email protected]> wrote: > Would this be a feasible approach for harmonising the AST between GHC and > TH too? > > Alan > On 2 Sep 2015 09:27, "Michael Smith" <[email protected]> wrote: > >> The package description for that is "The GHC compiler's view of the GHC >> package database format", and this doesn't really have to do with the >> package database format. Would it be okay to put this in there anyway? >> >> On Wed, Sep 2, 2015, 07:33 Simon Peyton Jones <[email protected]> >> wrote: >> >>> we already have such a shared library, I think: bin-package-db. would >>> that do? >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* ghc-devs [mailto:[email protected]] *On Behalf Of >>> *Michael >>> Smith >>> *Sent:* 02 September 2015 09:21 >>> *To:* Matthew Pickering >>> *Cc:* GHC developers >>> *Subject:* Re: Shared data type for extension flags >>> >>> >>> >>> That sounds like a good approach. Are there other things that would go >>> nicely >>> in a shared package like this, in addition to the extension data type? >>> >>> >>> >>> On Wed, Sep 2, 2015 at 1:00 AM, Matthew Pickering < >>> [email protected]> wrote: >>> >>> Surely the easiest way here (including for other tooling - ie >>> haskell-src-exts) is to create a package which just provides this >>> enumeration. GHC, cabal, th, haskell-src-exts and so on then all >>> depend on this package rather than creating their own enumeration. >>> >>> >>> On Wed, Sep 2, 2015 at 9:47 AM, Michael Smith <[email protected]> >>> wrote: >>> > #10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the >>> > capababilty >>> > to Template Haskell to detect which language extensions enabled. >>> > Unfortunately, >>> > since template-haskell can't depend on ghc (as ghc depends on >>> > template-haskell), >>> > it can't simply re-export the ExtensionFlag type from DynFlags to the >>> user. >>> > >>> > There is a second data type encoding the list of possible language >>> > extensions in >>> > the Cabal package, in Language.Haskell.Extension [3]. But >>> template-haskell >>> > doesn't already depend on Cabal, and doing so seems like it would cause >>> > difficulties, as the two packages can be upgraded separately. >>> > >>> > So adding this new feature to Template Haskell requires introducing a >>> > *third* >>> > data type for language extensions. It also requires enumerating this >>> full >>> > list >>> > in two more places, to convert back and forth between the TH Extension >>> data >>> > type >>> > and GHC's internal ExtensionFlag data type. >>> > >>> > Is there another way here? Can there be one single shared data type >>> for this >>> > somehow? >>> > >>> > [1] https://ghc.haskell.org/trac/ghc/ticket/10820 >>> > [2] https://phabricator.haskell.org/D1200 >>> > [3] >>> > >>> https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Extension.html >>> > >>> >>> > _______________________________________________ >>> > ghc-devs mailing list >>> > [email protected] >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> > >>> >>> >>> >> >> _______________________________________________ >> ghc-devs mailing list >> [email protected] >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >>
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
