Fix the bug where data types with infix names & names layed out over multiple lines get incorrectly formatted. Specifically, reuse `p_infixDefHelper` to easily take care of this behavior.
It is a bit uncommon to format it like this, but this way it can be placed
without changes in do blocks as well. I think it's the right way go about
that bug.
Now the printing code can correctly detect when hanging constructions should
be placed in non-hanging fashion from the way they are placed in input
source code.
Just like other pragmas annotations will now “stick” to the definitions they
pertain to. If it's not possible, there will be a newline separating them
from other declarations in the module.
Most syntactic constructs reuse pretty printing specified previously, such as arrow cases, if-expressions and lambdas. Relevant operators (such as arrow argument passing) and brackets are also formatted as operators and brackets typically are.
Certain other kinds of declarations, such as instance signatures (e.g., from `InstanceSigs`) and bindings, are grouped together without newlines. The process for determining which declarations are grouped reuses the same logic as for modules and type classes.
Certain other kinds of declarations (such as associated type signatures and
bindings) are grouped together without newlines. The process for determining
which declarations are grouped reuses the same logic as for modules.
* Point to more recent nixpkgs commit. This fixes build issue with python
3.7.3 (only on darwin?).
* Separate shell.nix and default.nix. This is so that lorri can be used for
development.
* Add nix output to .gitignore.
* Format *.nix using nixfmt.
* Use gitignore for filtering files in nix derivation.
There are no real problems to speak of, as the formatting is obvious and consistent with what the Haskell community already does.See the tests for an example.
The reason transform list comprehensions are not implemented yet is because the GHC AST for representing list comprehensions is ahorrible mess, where slightly different list comprehensions end upcausing massively different syntax trees. The simplest way of solving this would likely be a preprocessing step that reads the syntaxtrees and produces a simple, linear list of bindings. I decided not to implement this yet to avoid delaying this commit further.
The PR changes the body layouting to use a span that includes the last point in
the name/pattern part of a match. This forces the layout to be multiline iff the
body starts on a newline.
