Since we made all packages available in Ormolu Live by default in #1015, there are some surprising discrepancies between the CLI and Ormolu Live, for example:
```haskell
-- with -p lens
import Control.Lens
foo =
bar
& a .~ 1
& b .~ 2
```
```haskell
-- with -p lens
import Control.Lens
foo =
bar
& a
.~ 1
& b
.~ 2
```
Another example is the snippet from #1028. With this PR, all of them are now also fixed points in Ormolu Live.
The reason for this is that certain modules (Prelude and Control.Lens) are also defined in other packages than the "obvious" candidates, but the operators there are inferred to have a different fixity, so we get suboptimal layout as above.
Concretely, I have noticed two cases:
For certain (very old?) packages, the Hoogle DB does not include fixity information for (certain?) operators, such that extract-hackage-info has to assume the default fixity.
The package haskell2010 also defines the Prelude module, which also exports the $ operator, but the corresponding Hoogle .txt file does not contain any fixity info for $.
The package reasonable-lens defines the Control.Lens.Setter module (as does lens), which also exports the .~ operator, but again with no fixity info attached.
Sometimes, packages define an operator both at the value and at the type level with different fixity info (was already mentioned e.g. here).
A concrete example is morley-prelude, which defines a Prelude module and exports both the usual $ value-level operator (with the usual fixity infixr 0) and the $ type-level operator with fixity infixr 2.
We could think about improving this (most heavyweight solution would be to explicitly handle the different namespaces for Haskell names), but as already mentioned previously, it is not clear that this pays its weight.
In order to fix this in Ormolu Live, we are now excluding all packages that also define a module present in one of a few selected packages (currently, only base and lens). Concretely, the complement of liveDependencies is
In general, I don't think there are many packages that both share module names and suffer from operator fixity discrepancies due to one of the reasons above, so a static list seems fine to me.
github-actions[bot]
commented
1 year ago
Since we made all packages available in Ormolu Live by default in #1015, there are some surprising discrepancies between the CLI and Ormolu Live, for example:
Another example is the snippet from #1028. With this PR, all of them are now also fixed points in Ormolu Live.
The reason for this is that certain modules (
PreludeandControl.Lens) are also defined in other packages than the "obvious" candidates, but the operators there are inferred to have a different fixity, so we get suboptimal layout as above.Concretely, I have noticed two cases:
extract-hackage-infohas to assume the default fixity.Preludemodule, which also exports the$operator, but the corresponding Hoogle.txtfile does not contain any fixity info for$.Control.Lens.Settermodule (as doeslens), which also exports the.~operator, but again with no fixity info attached.Sometimes, packages define an operator both at the value and at the type level with different fixity info (was already mentioned e.g. here).
Preludemodule and exports both the usual$value-level operator (with the usual fixityinfixr 0) and the$type-level operator with fixityinfixr 2.We could think about improving this (most heavyweight solution would be to explicitly handle the different namespaces for Haskell names), but as already mentioned previously, it is not clear that this pays its weight.
In order to fix this in Ormolu Live, we are now excluding all packages that also define a module present in one of a few selected packages (currently, only
baseandlens). Concretely, the complement ofliveDependenciesisIn general, I don't think there are many packages that both share module names and suffer from operator fixity discrepancies due to one of the reasons above, so a static list seems fine to me.