If you're adding it to a cabal file then you need to modify Cabal, because it wants to mark packages as unbuildable on ghcs that don't support declared extensions. Placing it in source files avoids this, but you would have to modify all files that need to know about it (hopefully that doesn't mean all of `base`). On Sun, Mar 15, 2026 at 4:08 PM Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

Thanks. But where is this Cabal-syntax directory? How do I "bump the cabal version"?

I'm only trying to build GHC! I wasn't intending to modify cabal.

Simon

On Sun, 15 Mar 2026 at 17:26, Brandon Allbery wrote:

...

It goes in `Cabal-syntax/src/Language/Haskell/Extensions.hs`, in `data KnownExtension`. The parse table is built from the constructor names, and `No` prefixes are handled automatically. Note that you'll need to also bump the `cabal-version` (file format version) and add an entry to the file format documentation (`doc/file-format-changelog.rst`).

On Sun, Mar 15, 2026 at 1:18 PM Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote:

...

Friends

As part of the reinstallable base project I'm adding an extension "ImplicitKnownKeyNames" to GHC. But if I put "NoImplicitKnownKeyNames" in base.cabal.in I get the error

Warning: [unknown-extension] Unknown extensions: NoImplicitKnownKeyNames

when building the base library. I think this comes from cabal.

How can I tell cabal about the new extension?

Thanks

Simon _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

-- brandon s allbery kf8nh allbery.b@gmail.com

-- brandon s allbery kf8nh allbery.b@gmail.com

`ghc-options` is typically used only for fine control (e.g. `-f` options) or debugging (`-d` options). I think it warns if you stick a `-X` in there, but should accept it. Optimization is controlled by `optimization` in the cabal file or `cabal.project`. Some other known options are handled the same way, including extensions from `language` and `default-extensions`. On Sun, Mar 15, 2026 at 4:28 PM Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

It does mean every module in `base` and every module in `ghc-internal`. We already seem to have `NoImplicitPrelude` in each of them despite a `NoImplicitPrelude` in base.cabal.

There must be a better way than editing several hundred modules to add a one-line pragma. All I want to do is to get cabal to pass the flag to every module.

I thought there was a ghc-options directive in cabal? Maybe I can say ghc-options: -XNoImplicitKnownKeyNames and cabal will just pass it along?

But I don't see *any* ghc-options in base.cabal. How does cabal decide what options to pass to GHC when compiling base (e.g -O2)?

Simon

On Sun, 15 Mar 2026 at 20:15, Brandon Allbery wrote:

...

If you're adding it to a cabal file then you need to modify Cabal, because it wants to mark packages as unbuildable on ghcs that don't support declared extensions. Placing it in source files avoids this, but you would have to modify all files that need to know about it (hopefully that doesn't mean all of `base`).

On Sun, Mar 15, 2026 at 4:08 PM Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Thanks. But where is this Cabal-syntax directory? How do I "bump the cabal version"?

I'm only trying to build GHC! I wasn't intending to modify cabal.

Simon

On Sun, 15 Mar 2026 at 17:26, Brandon Allbery wrote:

...

It goes in `Cabal-syntax/src/Language/Haskell/Extensions.hs`, in `data KnownExtension`. The parse table is built from the constructor names, and `No` prefixes are handled automatically. Note that you'll need to also bump the `cabal-version` (file format version) and add an entry to the file format documentation (`doc/file-format-changelog.rst`).

On Sun, Mar 15, 2026 at 1:18 PM Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote:

...

Friends

As part of the reinstallable base project I'm adding an extension "ImplicitKnownKeyNames" to GHC. But if I put "NoImplicitKnownKeyNames" in base.cabal.in I get the error

Warning: [unknown-extension] Unknown extensions: NoImplicitKnownKeyNames

when building the base library. I think this comes from cabal.

How can I tell cabal about the new extension?

Thanks

Simon _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

-- brandon s allbery kf8nh allbery.b@gmail.com

-- brandon s allbery kf8nh allbery.b@gmail.com

-- brandon s allbery kf8nh allbery.b@gmail.com

I've been arguing that internally almost since I started working on it, tbh. On Sun, Mar 15, 2026 at 9:35 PM Moritz Angermann wrote:

I think this highlights another point where cabal is _way_ too tightly coupled with the haskell compiler.

On Mon, 16 Mar 2026 at 05:33, Brandon Allbery via ghc-devs < ghc-devs@haskell.org> wrote:

...

`ghc-options` is typically used only for fine control (e.g. `-f` options) or debugging (`-d` options). I think it warns if you stick a `-X` in there, but should accept it.

Optimization is controlled by `optimization` in the cabal file or `cabal.project`. Some other known options are handled the same way, including extensions from `language` and `default-extensions`.

On Sun, Mar 15, 2026 at 4:28 PM Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

It does mean every module in `base` and every module in `ghc-internal`. We already seem to have `NoImplicitPrelude` in each of them despite a `NoImplicitPrelude` in base.cabal.

There must be a better way than editing several hundred modules to add a one-line pragma. All I want to do is to get cabal to pass the flag to every module.

I thought there was a ghc-options directive in cabal? Maybe I can say ghc-options: -XNoImplicitKnownKeyNames and cabal will just pass it along?

But I don't see *any* ghc-options in base.cabal. How does cabal decide what options to pass to GHC when compiling base (e.g -O2)?

Simon

On Sun, 15 Mar 2026 at 20:15, Brandon Allbery wrote:

...

If you're adding it to a cabal file then you need to modify Cabal, because it wants to mark packages as unbuildable on ghcs that don't support declared extensions. Placing it in source files avoids this, but you would have to modify all files that need to know about it (hopefully that doesn't mean all of `base`).

On Sun, Mar 15, 2026 at 4:08 PM Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Thanks. But where is this Cabal-syntax directory? How do I "bump the cabal version"?

I'm only trying to build GHC! I wasn't intending to modify cabal.

Simon

On Sun, 15 Mar 2026 at 17:26, Brandon Allbery wrote:

...

It goes in `Cabal-syntax/src/Language/Haskell/Extensions.hs`, in `data KnownExtension`. The parse table is built from the constructor names, and `No` prefixes are handled automatically. Note that you'll need to also bump the `cabal-version` (file format version) and add an entry to the file format documentation (`doc/file-format-changelog.rst`).

On Sun, Mar 15, 2026 at 1:18 PM Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote:

> Friends > > As part of the reinstallable base project I'm adding an > extension "ImplicitKnownKeyNames" to GHC. But if I put > "NoImplicitKnownKeyNames" in base.cabal.in I get the error > > Warning: [unknown-extension] Unknown extensions: > NoImplicitKnownKeyNames > > when building the base library. I think this comes from cabal. > > How can I tell cabal about the new extension? > > Thanks > > Simon > _______________________________________________ > ghc-devs mailing list -- ghc-devs@haskell.org > To unsubscribe send an email to ghc-devs-leave@haskell.org >

-- brandon s allbery kf8nh allbery.b@gmail.com

-- brandon s allbery kf8nh allbery.b@gmail.com

-- brandon s allbery kf8nh allbery.b@gmail.com _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

-- brandon s allbery kf8nh allbery.b@gmail.com

I'd argue that one is the fault of Backpack itself: it's inherently GHC-specific and was intended to be used with tooling (that is, Cabal). It really needed to be a language feature instead of a tooling hack, IMO. On Sun, Mar 15, 2026 at 11:19 PM amindfv@mailbox.org wrote:

On Mon, Mar 16, 2026 at 10:35:45AM +0900, Moritz Angermann via ghc-devs wrote:

...

I think this highlights another point where cabal is _way_ too tightly coupled with the haskell compiler.

Another example might be the apparently-tight coupling between Backpack and Cabal.

Cheers, Tom

-- brandon s allbery kf8nh allbery.b@gmail.com

I'm entirely open to this being a GHC flag rather than a language extension flag. I was just following the pattern of NoImplicitPrelude. I'll get a bit further, document my progress, and invite public feedback. Simon On Mon, 16 Mar 2026 at 16:03, Brandon Allbery wrote:

TBH I'm inclined to agree with this. In particular, I think of language extensions as things that potentially could find their way into a standard (or quasi-standard like `GHC2xxx`). As such, there may be a couple of others that could use a look. (`NoImplicitPrelude` I would not consider such, since it's useful with alternative preludes.)