lspitzner / brittany

haskell source code formatter
GNU Affero General Public License v3.0
690 stars 72 forks source link

Very long type signatures are not dealt with well #299

Open infinity0 opened 4 years ago

infinity0 commented 4 years ago

Consider the following type signature. Under the default settings, brittany version 0.12.1.1 does:

xxx
  :: forall c0 c1 c2 c3 c4 c5 c6 c7 c8 c9
   . c0 Integer
  -> c1 Integer
  -> c2 Integer
  -> c3 Integer
  -> c4 Integer
  -> c5 Integer
  -> c6 Integer
  -> c7 Integer
  -> c8 Integer
  -> c9 Integer
  -> c0 Integer
  -> c1 Integer
  -> c2 Integer
  -> c3 Integer
  -> c4 Integer
  -> c5 Integer
  -> c6 Integer
  -> c7 Integer
  -> c8 Integer
  -> c9 Integer
xxx = undefined

Not great, but not terrible. However if you extend the type signature by just a little bit more:

xxx
  :: forall
       c0
       c1
       c2
       c3
       c4
       c5
       c6
       c7
       c8
       c9
   . c0 Integer
  -> c1 Integer
  -> c2 Integer
  -> c3 Integer
  -> c4 Integer
  -> c5 Integer
  -> c6 Integer
  -> c7 Integer
  -> c8 Integer
  -> c9 Integer
  -> c0 Integer
  -> c1 Integer
  -> c2 Integer
  -> c3 Integer
  -> c4 Integer
  -> c5 Integer
  -> c6 Integer
  -> c7 Integer
  -> c8 Integer
  -> c9 Integer
  -> c0 Integer
  -> c1 Integer
  -> c2
       Integer
  -> c3
       Integer
  -> c4
       Integer
  -> c5
       Integer
  -> c6
       Integer
  -> c7
       Integer
  -> c8
       Integer
  -> c9
       Integer

Wow, what has happened here? Why all the extra unnecessary line breaks???

(Yes, regrettably my "real use-case" signature is similar, I am coding with dependent types. :disappointed: )

infinity0 commented 4 years ago

I tried screwing around with the config but it doesn't help either - lconfig_hangingTypeSignature: true doesn't affect this.

lspitzner commented 4 years ago

Thanks for the reproduction case.

I am almost tempted to debug why exactly this happens, but this can and should best be resolved by rewriting the HsFunTy{} layouter, using the same technique that the value-level nested-operator layouter uses. Might even be able to remove the docForceMultiline construct after that and clean up the low-level stuff a bit.