Shared data type for extension flags

Simon Peyton Jones simonpj at
Wed Sep 2 14:33:23 UTC 2015

we already have such a shared library, I think: bin-package-db.  would that do?


From: ghc-devs [mailto:ghc-devs-bounces at] 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 <matthewtpickering at<mailto:matthewtpickering at>> 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 <michael at<mailto:michael at>> 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]
> [2]
> [3]
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at<mailto:ghc-devs at>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list