Strange rendering of interface inside module.

[rossc719g]

I am noticing some strange coloring when declaring the interface of a module.

E.g.:

interface Foo =
  bar :: Bit 0

mkFoo :: (IsModule m c) => m Foo
mkFoo = module
  interface Foo    -- On this line
    bar = 0

On the indicated line, the "Fo" is in blue, but the last "o" is in white:

Strange huh?
It seems to happen for all my modules.

[quark17]

The problem doesn't occur if you include the -- On this line comment. I was briefly confused, because I copy-pasted the example and wasn't seeing the issue! But now I am, after removing the comment, and yes that's odd.

FYI, one way to see what the grammar is doing is to run the snapshot generator (that is used by the testsuite). For example:

npx vscode-tmgrammar-snap --config /path/to/language-bh/package.json -g /path/to/language-bh/syntaxes/bh.json -u Test.bs

I think that will ask you if you want to install any needed packages, but you can also do this:

npm install -g vscode-tmgrammar-test

Running the snapshot command will generate a text file Test.bs.snap, that shows inferred information. If you run the same command without -u, then it will check that the source and snapshot match.

Interestingly, if I generate the snapshot and then check it, I get an error! I'm not sure how that can happen! But the error is on the Foo that is displaying wrong (in the interface inside the module). The error message purports to show a diff (- for existing snapshot and + for the new changes), but there is no output for either shown!

One thing I do notice in the syntax YAML is that interface seems to be only declared as a keyword for datatype declarations. There's nothing to recognizes it for value construction. But I don't know that that would be the cause of why the final o looks different when there's no comment? Unless ... maybe the highlighting of data types is expecting something at the end of the line, like =, and so it expects to end before the last character is reached, or something?

Ah! If I rewrite the datatype declaration to put the = on the next line, then I also see the white o in that situation too:

interface Foo
  = bar :: Bit 0

[quark17]

Also, this website seems useful: https://regex101.com/

You can type in a regex in the top box, and then type text in the bottom box, and it shows you what part of the bottom text is matched by the regex, using colors to correlate between the two (the colors are listed in a block on the right) and there's also a block (on the right) that gives an explanation of the parts of the regex! If I copy in the regex for data declaration (lines 125-141 of the YAML), I can see that the second o is highlighted differently. What I see in the "match information" block on the right is that Foo does get matched (as group 3) but that the final o is also matched (as group 4).

I don't understand enough yet to know how to fix it, though. But I do note that the following also have poor highlighting on the second o:

interface Foo=

interface Foo{- -} =

[quark17]

Ah! I think one of the (...) groups needs to be (?:...), which is the same but doesn't bind the contents to a new identifier. To explain:

The regex that matches Foo has the form: ((?!X).)*. This says to match all characters up until X. This is like .* but it adds (?!...) which is "negative lookahead" that asserts that the given pattern doesn't match. So ((?!X).)* consumes all characters that don't start the pattern X.

When you write parens, that declares a new group (which can be accessed by number). If you write (.)*, the group will only refer to the last character matched, not to all the characters. The regex website helpfully tells us this in the "explanation" pane:

A repeated capturing group will only capture the last iteration. Put a capturing group around the repeated group to capture all iterations or use a non-capturing group instead if you're not interested in the data

So, you'll notice, the syntax highlighter adds parens around it: (((?!X).)*). However, this now has two groups, one for the whole string and one for the last character! To make the regex not bind the last match as its own group, we can use (?:...), like this: ((?:(?!X).)*). If I type this into the regexp website, I see that the last character is no longer highlighted differently. And if I make this change in the YAML, then it fixes the issue in VSCode. Specifically, line 129:

# Keep consuming characters until:
((?:(?!

That said...

The regex for matching Foo is greedily accepting all characters until either an equals, where, deriving, or a block comment. That seems like it can match way too much. Shouldn't it just be a pattern like ([A-Z][A-Za-z_']*) that matches all contiguous identifier letters (starting with capital)?

Although maybe we do need to match more, because the interface name may be wrapper in a kind signature:

interface (Foo :: # -> *) n =
  bar :: Bit n