`x!=y` interpreted as `x! = y` due to `!` being allowed in identifiers

[Jiří Beneš]

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.

[Marcial Gaißert]

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.

[Jonathan Immanuel Brachthäuser]

Just tagging @dvdvgt since this might be relevant for him.

[Jonathan Immanuel Brachthäuser]

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.

[dvdvgt]

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?

[dvdvgt]

Also, similarly: n-1 lexes as n -1 (not as n - 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.

[Jonathan Immanuel Brachthäuser]

As I said, I wouldn't want to fix this. People should use whitespaces if they mean n - 1.

[dvdvgt]

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.

[Marcial Gaißert]

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).

[Jonathan Immanuel Brachthäuser]

The easiest way to disallow it is to allow - as part of an identifier ;)