`x!=y` interpreted as `x! = y` due to `!` being allowed in identifiers
jiribenes opened this issue · comments
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 e8a1477.
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-1
lexes 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 ;)