-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle "default-extensions" in *.cabal file #56
Comments
I think right now users are expected to have a configuration file and then feed it with |
Do you have a pointer for how this configuration file would look like? |
This seems to be the format: ghc-opts:
- -XLambdaCase
unsafe: False
debug: False |
Another idea would be to be able to point the formatter at a |
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. |
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. |
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". |
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 |
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. |
Neither new-style 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 |
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. |
Whatever logic Cabal uses to figure out the flags, it should not be duplicated. For example, the user might specify The best way to integrate with tooling is to mimic the compiler. Pretend that the formatter is |
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 Pretending to be a compiler is robust. |
I'm
default-extensions
in my *.cabal file. ormolu doesn't look at these, and thus reports syntax errors.The text was updated successfully, but these errors were encountered: