Incorrect highlighting for multi-line signatures.

[pascalpoizat]

Hello,

First of all, thanks a lot for all your work on the plugin.
I have an issue with multi-line signatures (as formatted by Brittany).
The rendering of types in lines 2..n of the signature is not consistent with line 1 (it looks like constructors rather than types).

See, eg,

vs (expected)

This could possibly be linked to #1.
Nb: I have seen also #27.

I am using:

• VSC 1.24.1
• Haskell Syntax 2.5.0 (but in the Changelog in VSC I see 3.0.0)
• Haskell Language Server 0.0.19
• HIE 0.2.0.0

[pascalpoizat]

I found a solution that seems to work following lspitzner/brittany#94.
With this configuration brittany formats the signature in a slightly different way that is ok wrt the syntax highlighting.

Therefore, I think the issue can be closed.

[JustusAdam]

Yeah, this is a known issue. Due to how the grammar files work parsing Haskell correctly is rather difficult. I am still unsure whether it is at all possible to write a grammar for this but unfortunately I don't have the time to investigate it currently.

[pascalpoizat]

Hello @JustusAdam ,

I think the issue there comes from not parameterizing correctly Brittany (my fault).
I did not closed directly the issue because I thought you may possibly want to add some comment somewhere about the fact that some forms are not supported and the pretty-printers (Brittany, or other) can be parameterized to yield a nice result.

Best,

Pascal

[JustusAdam]

Well, its not really your fault though. My personal beliefe is that the syntax highlighter should be able to correctly highlight anything that the compiler also accepts.
Unfortunately it seems this is either impossible or at least pretty hard with the limitations imposed by the vscode/atom/texmate grammars. If you want an editor that can also handle the form with the double colon on the next line I can recommend emacs. In emacs the syntax highlighters can use a full fledged parser and is not restricted in the same way it is with vscode and thus they correctly handle that case.

[domenkozar]

I wonder then why didn't the atom highlighting have this bug since it also uses texmate syntax?

[sheaf]

It's not possible to highlight the function name as we would need to be able to look ahead on subsequent lines to see if we can find a double colon, which isn't possible with TextMate grammars.

However it is possible to highlight the type signature, after the double colon (implemented in 3695e33). So it'll just be the function definition that won't have the expected highlighting.

Note that Atom TextMate highlighting (as used on GitHub) suffers from the same limitation:

foo :: A -> B

foo
  :: A
  -> B

[domenkozar]

Thank you.

[JustusAdam]

So because I've just, again, spent 15 minutes trying to figure out if it is possible I want to put down my reasoning here so next time I inevitably see this issue again I can just read why its impossible.

1. It is very possible to match the identifier with a begin and thus capture the whole declaration by combining all the possible end conditions (Though I think they all are "End when less or same indentation line"), however

2. When we match the identifier(line) we do not yet know what it is. At this point, from the perspective of the parser, we cannot disambiguate between

   • declaration (would be followed by ::)
   • definition (would be followed by =), or even worse
   • template Haskell (would be followed by nothing)

   because these are on one of the the following lines, and we can only do look-ahead up to the end of the line.

3. We can match these following symbols in a patterns clause but by the time we do, we're stuck in that pattern clause and there is no way to refer back to the thing we matched with begin to say "this thing is function/definition/th"

In conclusion: It is possible to match declarations/definitions but by the time we disambiguate we can't refer to the identifier anymore to give it the correct textmate scope.