Highlight overloaded labels about language-haskell HOT 5 CLOSED

I am currently contemplating how to implement this. The problem is that with the overloaded labels it is inherently ambiguous for any label that occurs as the leftmost lexeme whether it is a label or a c preprocessor instruction.

I see three possible ways of resolving this:

1. Bias: Either leave it as it is (only parse preprocessors) or parse them all as labels.
2. Leftmost is C: Make all labels, unless its only preceeded by whitespace on the left.
   Kinda handles both but would not do case-1 in your example correctly
3. Top-level is C: Only parse it as C, then it starts the line, and is not preceded by whitespace.
   Handles your case-1 correctly, but will handle many actual CPP applications wrong. Might be tolerable though, since the most common use is simple, tope level #if or #ifdef. However may be very confusing in the cases where this does occur.
4. Known directive: Only parse known CPP directives. I.e. #if, #else, #define, #include (plus only if they are leftmost, i.e. 2)

My favorite is option 4. I think this will cause the least disruption and handle almost all usual cases well.

I'd appreciate some input from you @sheaf and also @poscat0x04, since you also expressed interest in this.

from language-haskell.

I just did a silly test:

{-# LANGUAGE CPP #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE OverloadedLabels #-}

module Main where

import GHC.OverloadedLabels

instance r ~ ( Int -> IO Int -> () -> IO Int -> () -> IO Int ) => IsLabel "if" r where
  fromLabel c =
    if c /= 0
    then \ t _ _ _ -> fmap negate t
    else \ _ _ f _ -> fmap negate f
instance r ~ () => IsLabel "else" r where
  fromLabel = ()
instance r ~ () => IsLabel "endif" r where
  fromLabel = ()

x :: IO Int
x = do {
#if 0
  ( pure 1 )
#else
  ( pure 2 )
#endif
}

main :: IO ()
main = print =<< x

The result here is -2, and if you remove the CPP extension, it still compiles but now the result becomes 2. So in this edge case, the syntax is inherently ambiguous and depends on the enabled language extensions.

At any rate, solution (4.) seems plenty good enough, as the above is realistically not going to occur in practice... never have I come across an overloaded label starting on the first character of a line.

from language-haskell.

I added support for overloaded labels in 34f27a4. I made the decision to only allow CPP instructions starting on the beginning of a line. That is, I am using approach (2) above. I figured it can be useful to allow other CPP directives, especially for tools like C2hs and Hsc2Hs (although those could have custom overriding rules).

So, other than # on the start of a line, prefix ocurrences of # are parsed as an overloaded label.

from language-haskell.

I think that's good enough for now, but I'd like to leave this issue open as a reminder and eventually implement (4)

from language-haskell.

Actually I've decided to instead open a new issue for this, as it does not concern labels anymore but the highlighting of CPP

from language-haskell.