Handle "default-extensions" in *.cabal file

[eschnett]

I'm default-extensions in my *.cabal file. ormolu doesn't look at these, and thus reports syntax errors.

[mrkkrp]

I think right now users are expected to have a configuration file and then feed it with -c or --config option. In future it may make sense to try to detect *.cabal file and fetch default extensions from there. Low priority for now, because we need to cover all stuff in GHC AST first.

[eschnett]

Do you have a pointer for how this configuration file would look like?

[patrickmn]

This seems to be the format:

ghc-opts:
  - -XLambdaCase
unsafe: False
debug: False

[quasicomputational]

Another idea would be to be able to point the formatter at a .cabal file, which would instruct it to go off and format every source file referenced in the package description, using appropriate default-extensions.

[mboes]

There are a lot of advantages to repeating all extensions at the top of every source file. That makes them self-contained. Which means that source code analysis tools like Ormolu don't need any out-of-band information that's hard to feed to them.

[eschnett]

I'm not arguing either way for Ormolu, but:

@mboes: Haskell source files aren't quite self-contained. Operator fixity depends on import statements, and that's presumably something that a formatter wants to take into account.

[mboes]

But source files contain all the metadata necessary (import statements) in order to resolve operator fixity. By self-contained I don't mean "don't read anything else on the disk".

[quasicomputational]

You can't (accurately) resolve imports and hence determine fixities without knowing dependency bounds, so that would seem to also require finding and processing the .cabal file. Using your 'self-contained' criterion, fixity information also seems to point towards using the .cabal file as the entry point, since all the Haskell sources are then just a read from disk away.

[aspiwack]

I don't believe this to be correct: ghc doesn't know anything about cabal. When parsing a file, ghc takes the imported modules from its package database, which is considered a given. It may well have been provided by cabal, but it's unimportant at that particular time.

[quasicomputational]

Neither new-style cabal-install nor stack put their package databases anywhere GHC will look by default. They call GHC and specifically provide paths to where they've stuffed their package databases; I think that both tools treat those locations as an implementation detail that other tools aren't meant to rely on, but I might be wrong about that. (Nix does use GHC's well-known package database locations, IIRC, though.) (Edit: And I've just remembered that cabal v2-exec is a thing and I'm pretty sure that Stack also has something equivalent, so that actually solves the problem of figuring out dependencies!)

Anyway, this isn't a hill I want to die on and I'll try not to divert the thread. I'm just trying to make the point that looking at packages, rather than individual source files, as the unit of operation can be a useful perspective and make some things easier, including dealing with default-extensions.

[patrickmn]

IMO given the prevalence of default-extensions and the intent(?) of mass-adoption of this tool, it would be silly not to have an easy way to use the same language extensions, whether the user has defined those at a package or file level.

That said, it's not too hard for a user to put all their extensions in the config -- it just took a while to reverse-engineer the format.

[int-index]

In future it may make sense to try to detect *.cabal file and fetch default extensions from there.

Whatever logic Cabal uses to figure out the flags, it should not be duplicated. For example, the user might specify ghc-options: -XSomeExtension instead of default-extensions: SomeExtension.

The best way to integrate with tooling is to mimic the compiler. Pretend that the formatter is ghc and run the build. Ignore the GHC options that you have no use for but take e.g. language extensions into account.

[int-index]

Alternatively, Cabal must be extended with tooling support, e.g. have a first-class notion of a source code formatter or a static analysis tool. This way is cleaner, but then you'll have to do the same for stack, and then for Nix, and then for Bazel, and then whatever other build tool people can come up with.

Pretending to be a compiler is robust.