Opened 7 years ago

Closed 7 years ago

Last modified 22 months ago

#4437 closed bug (fixed)

unregistered language extensions

Reported by: duncan Owned by:
Priority: normal Milestone:
Component: Compiler Version:
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: T4437
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


There is a central registry of language extensions in the module Language.Haskell.Extension (which currently lives in the Cabal package). This lists all the registered extensions for all compilers. Compiler authors are expected to register their extensions there. It helps to avoid people giving different names to the same thing (see e.g. RecordPuns vs NamedFieldPuns) and provides a starting point for compiler authors to implement extension supported by other compilers. It also provides a resource for users trying to work out the name of the extension they need.

Hackage also consults this list of registered extensions and does not allow distributed packages to use unknown extensions.

It is currently too easy to forget to register extensions that GHC supports. Attached is a test program that lists unregistered extensions. This should be integrated into the ghc testsuite.

The test currently fails with the message:

The following extensions are known to GHC but are not in the 
extension registry in Language.Haskell.Extension.
If these extensions are ready for public consumption then they 
should be registered. If they are still experimental and you 
think they are not ready to be registered then please add them 
to the exceptions list in this test program along with an 

It seems clear that apart from GHCForeignImportPrim, all the other extensions should be registered. Note that it may be necessary to register the "No" form of some of these instead (see

Not all extensions need to be, or should be registered. It is OK to have experimental or purely private extensions (e.g. perhaps might want to restrict use to GHC core libs). To support this, the test program has a list of exceptions. Currently the list is:

-- | A list of GHC extensions that are deliberately not registered,
-- e.g. due to being experimental and not ready for public consumption
exceptions = map readExtension
  [ "PArr"   -- still classed as experimental, will be renamed and registered

A decision needs to be made about whether GHCForeignImportPrim should be registered. One could argue that it should remain private. The key point to consider is that it would prevent the extension being used in packages distributed on hackage.

Attachments (1)

ghc-supported-languages.hs (3.5 KB) - added by duncan 7 years ago.
Test program to check for unregistered ghc extensions

Download all attachments as: .zip

Change History (4)

Changed 7 years ago by duncan

Attachment: ghc-supported-languages.hs added

Test program to check for unregistered ghc extensions

comment:1 Changed 7 years ago by duncan

Note the list of unregistered extensions above is for ghc-6.12.1, there are undoubtedly more in ghc 7.0.

comment:2 Changed 7 years ago by igloo

Resolution: fixed
Status: newclosed
Test Case: T4437

Thanks, I've added a test to GHC's testsuite.

comment:3 Changed 22 months ago by Ben Gamari <ben@…>

In 7861a225/ghc:

Add a note describing the protocol for adding a language extension

Reviewers: hvr, thomie, austin

Reviewed By: austin

Subscribers: duncan

Differential Revision:

GHC Trac Issues: #8176, #4437
Note: See TracTickets for help on using tickets.