Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Highlight overloaded labels #68

Closed
sheaf opened this issue Nov 5, 2018 · 5 comments
Closed

Highlight overloaded labels #68

sheaf opened this issue Nov 5, 2018 · 5 comments

Comments

@sheaf
Copy link
Collaborator

sheaf commented Nov 5, 2018

There should be a rule for overloaded labels. Currently they are sometimes identifier as C preprocessor instructions, and otherwise parsed as an operator applied to an identifier.

overloaded_labels

@JustusAdam
Copy link
Owner

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.

@sheaf
Copy link
Collaborator Author

sheaf commented Apr 21, 2020

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.

@sheaf
Copy link
Collaborator Author

sheaf commented May 7, 2020

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.

@sheaf sheaf closed this as completed May 7, 2020
@JustusAdam
Copy link
Owner

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

@JustusAdam
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants