Opened 19 months ago

Closed 16 months ago

Last modified 16 months ago

#10820 closed feature request (fixed)

Provide a way to detect what extensions are enabled via TH

Reported by: spinda Owned by: spinda
Priority: normal Milestone: 8.0.1
Component: Template Haskell Version: 7.10.2
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: th/T18020.hs
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D1200
Wiki Page:

Description (last modified by bgamari)

This would be helpful for providing users with intuitive/explanatory error messages if generated code relies on an extension that the user may not have enabled.

Sample specification, to get things started:

enabledExts :: Q [Extension]
isExtEnabled :: Extension -> Q Bool
data Extension = LiberalTypeSynonyms | RankNTypes | ...
    -- mirroring ExtensionFlag in DynFlags

See #10819 for an example case where this could be of use.

Change History (9)

comment:1 Changed 19 months ago by spinda

Description: modified (diff)

comment:2 Changed 19 months ago by goldfire

Milestone: 7.12.1

I've wanted this, too. It should be able to happen by 7.12.

But, what data type to use for the extensions? Would it work to have template-haskell depend on Cabal to pull the extension type from there? My guess: no. Would it work to have template-haskell depend on ghc and pull the type from DynFlags? My guess: yes.

comment:3 Changed 19 months ago by spinda

Would it work to have template-haskell depend on ghc and pull the type from DynFlags? My guess: yes.

Wouldn't this create a mutually recursive package dependency, as ghc already depends on template-haskell? (see ghc.cabal.in and TcSplice)

comment:4 Changed 19 months ago by goldfire

Bah. Of course you're right. And I don't think it's a great idea to depend on Cabal because that package can be upgraded independently of GHC. Correct me if this wouldn't cause pain.

I guess we could have Yet Another List Of Extensions.

comment:5 Changed 19 months ago by spinda

Differential Rev(s): Phab:D1200
Owner: set to spinda
Test Case: th/T18020.hs

comment:6 Changed 19 months ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:7 Changed 16 months ago by Ben Gamari <ben@…>

In c1e2553/ghc:

Expose enabled language extensions to TH

This exposes `template-haskell` functions for querying the language
extensions which are enabled when compiling a module,

- an `isExtEnabled` function to check whether an extension is enabled
- an `extsEnabled` function to obtain a full list of enabled extensions

To avoid code duplication this adds a `GHC.LanguageExtensions` module to
`ghc-boot` and moves `DynFlags.ExtensionFlag` into it. A happy
consequence of this is that the ungainly `DynFlags` lost around 500
lines. Moreover, flags corresponding to language extensions are now
clearly distinguished from other flags due to the `LangExt.*` prefix.

Updates haddock submodule.

This fixes #10820.

Test Plan: validate

Reviewers: austin, spinda, hvr, goldfire, alanz

Reviewed By: goldfire

Subscribers: mpickering, RyanGlScott, hvr, simonpj, thomie

Differential Revision: https://phabricator.haskell.org/D1200

GHC Trac Issues: #10820

comment:8 Changed 16 months ago by bgamari

Resolution: fixed
Status: newclosed

comment:9 Changed 16 months ago by bgamari

Description: modified (diff)
Note: See TracTickets for help on using tickets.