brittany insists on ExplicitNamespaces declared at top of file and nowhere else.

[dspies-leapyear]

When my package.yaml file already includes TypeFamilies and TypeOperators, brittany complains when I do an explicit import:

import Data.Singletons.Prelude(type (++))

even though GHC is fine with this.

Illegal keyword 'type' (use ExplicitNamespaces to enable)

Even if I add ExplicitNamespaces to my package.yaml/cabal file, brittany still complains. It only seems to be happy if I put it as a pragma at the top of the file.

[tfausak]

Brittany doesn't read the default extensions from your package.yaml or *.cabal file. You'll have to either pass in your extensions as options or set them in your brittany.yaml config. See this section of the readme: https://github.com/lspitzner/brittany/blob/6c187da/README.md#usage

[dspies-leapyear]

That's strange. I regularly put all of (among other things)

LambdaCase
GADTs
ViewPatterns
ExplicitForAll (via ScopedTypeVariables and RankNTypes)

as default extensions in my package.yaml file and I've never had brittany complain about any of them.

[tfausak]

You may have some extensions enabled in your personal config (~/.config/brittany/config.yaml).

$ brittany --version
brittany version 0.11.0.0
Copyright (C) 2016-2018 Lennart Spitzner
There is NO WARRANTY, to the extent permitted by law.

$ echo 'f = \\ case { () -> () }' | brittany
parse error:
"RealSrcSpan SrcSpanOneLine \"stdin\" 1 7 11: parse error on input \8216case\8217"

$ echo 'f :: forall a . a' | brittany 
parse error:
"RealSrcSpan SrcSpanOneLine \"stdin\" 1 15 16: Illegal symbol '.' in type\nPerhaps you intended to use RankNTypes or a similar language\nextension to enable explicit-forall syntax: forall <tvs>. <type>"

However I think Brittany correctly handles some of these things by simply passing them through.

$ printf 'data T where\n C :: T\n' | brittany
data T where
 C :: T

$ echo 'f (e -> p) = ()' | brittany
f (e -> p) = ()

[lspitzner]

You may have some extensions enabled in your personal config (~/.config/brittany/config.yaml).

This would be my guess as well.

There is --dump-config that will contain, among other stuff, the full listing of extensions enabled via any sort of per-user/per-project config files. Brittany should accept any syntax if and only if it is mentioned there or per "LANGUAGE" pragma in the input.

[dspies-leapyear]

It didn't, but in any case the fix works. I should close this.