I don't think it makes very much sense to reuse bin-package-db; at least, not without renaming it at the very least (who'd expect a list of language extension flags to live in a binary package database?) We could name it something like 'ghc-types'?
Edward Excerpts from Simon Peyton Jones's message of 2015-09-08 05:35:00 -0700: > Yes, we’d have to broaden the description of the package. I defer to Edward > Yang and Duncan Coutts who have a clearer idea of the architecture in this > area. > > Simon > > From: Michael Smith [mailto:mich...@diglumi.com] > Sent: 02 September 2015 17:27 > To: Simon Peyton Jones; Matthew Pickering > Cc: GHC developers > Subject: Re: Shared data type for extension flags > > > 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 > <simo...@microsoft.com<mailto:simo...@microsoft.com>> wrote: > we already have such a shared library, I think: bin-package-db. would that > do? > > Simon > > From: ghc-devs > [mailto:ghc-devs-boun...@haskell.org<mailto:ghc-devs-boun...@haskell.org>] 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 > <matthewtpicker...@gmail.com<mailto:matthewtpicker...@gmail.com>> 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 > <mich...@diglumi.com<mailto:mich...@diglumi.com>> 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 > > ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
