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
