Backpack .hsig file support

[poscat0x04]

see https://wiki.haskell.org/Module_signature

[mrkkrp]

I looked a little bit at this today. This is quite doable, but requires using a different parser and an extra printer.

• To parse Haskell we use parseModule, but for Backpack we need to use parseBackpack instead.
• Need a new printer.
• The dispatch should probably be done by file extension, but there also should be an explicit switch, because stdin doesn't have file extension for example.

[tbagrel1]

EDIT: no longer valid, see #600 (comment)

As far as we know, it seems that two syntax exist for backpack files:

• The one understood by the GHC-lib-parser parseBackpack function, which is kinda strict:
  • a top level unit <...> where declaration is mandatory
  • indentation should be present after unit <...> where \n and module <...> where \n
• The one effectively used by Cabal, which seems more permissive (for example, this file effectively works with cabal, but cannot be parsed by parseBackpack because of the missing unit <...> where \n declaration)

Because of the way ormolu works, we have no choice than to use the experimental parseBackpack function from GHC-lib-parser. As a result, for the moment, some valid Cabal .hsig files won't be accepted by our formatter.

We could maybe allow "partial" Backpack files to be processed with ormolu by introducing the required unit <...> where \n and correct indentation before handing the file to the parser if the first parsing try fails.

EDIT: at the moment, with the associated PR, all the (GHC variant) Backpack related syntax is implemented in ormolu. However, AST diffing and import sorting is not made correctly, so ormolu can only be used in --unsafe mode (fixed)

[tbagrel1]

Haven't had time to read it yet, but this might give some interesting info on backpack

[mrkkrp]

I think we can try to look at what Cabal is doing and, unless it is overly complicated, we could do the same. We already depend on the Cabal library, so that is probably not very hard.

[tbagrel1]

After a long investigation, we found that signature files are not handled by Cabal itself, but directly by GHC, using the GHC lib parser parseSignature function.

parseBackpack only exists for testing purpose, allowing to write a complete backpack example in just one file. In the real world, a signature file only contains one top-level signature <name> where declaration (analog to a top-level module declaration), and dependency links between modules and signatures are written in the <project>.cabal file.

So the "Cabal" syntax is the correct one, and the so-called "GHC" syntax in the previous comment is only made for experimentation.

As a result, the blockers listed in the previous comment are no longer valid. The discussion of the implementation for this feature will continue in the associated PR.