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
