`x!=y` interpreted as `x! = y` due to `!` being allowed in identifiers
As discovered by @marzipankaiser, right now, x!=y without spaces gets parsed as:
`x!` (identifier), `=` (binary operation assign), `y` (identifier)
whereas I'd expect it to be the same as before:
`x` (identifier), `!=` (binary operation not equal to), `y` (identifier)
This is caused by supporting ! in identifiers introduced in https://github.com/effekt-lang/effekt/commit/e8a14778f99524601aa8bcd62541aa46529241a0.
Note, this is still the case on current master.
Also, similarly: n-1 lexes as n -1 (not as n - 1) and fails during parsing.
Just tagging @dvdvgt since this might be relevant for him.
To be honest, I think the latter (n-1 not parsing) is a feature, not a bug :) I am happy with nudging people to use whitespace.
I fail to see what we can do about it to completely avoid this issue:
- Either disallow
!occurring in identifiers, - force the user to add a space
- or have it the other way around such that there may be a falsely lexed
!=where it is actually an identifier ending with a!.
How else should the lexer know that val n!=1 contains the identifier n! and and the token = but not != instead without taking the context into consideration?
Also, similarly:
n-1lexes asn-1(not asn-1) and fails during parsing.
This should be fixable by allowing the lexer only to lex unsigned numbers and let parser figure out the precedence.
As I said, I wouldn't want to fix this. People should use whitespaces if they mean n - 1.
As much as I like the frequent and consistent use whitespaces to structure code, I disagree. I don't think arithmetics is the right place to force this onto the user. Parsing should be robust enough to handle something like 1-1 (instead of 1 - 1) without aborting the whole compilation.
As I said, I wouldn't want to fix this. People should use whitespaces if they mean
n - 1.
I'm somewhat fine with this (though I sometimes do prefer the version without whitespace), but then we should be consistent and also disallow n- 1 (which is parsing fine).
The easiest way to disallow it is to allow - as part of an identifier ;)