Even if the lexer creates a single lexeme for ">=", the parser could still accept it as a fallback but this requires splitting parsing rules for matching the next "=" within the context of use (an assignment statement). This may seem inelegant, but that's what is done actually in complete parser s that would have to work around would would be otherwise a syntax error with an unexpected token.
However you could as well drop the ">=" token and always treat it as two tokens (optionally separated by spaces/comments) without creating syntaxic ambiguities in expressions expecting the binary comparator. just consider, this code:
if x > = 0 then
end
Is it really ambiguous for programmers and more difficult to parse ?
As well for other diagrams used in operators, which could be parsed more leniently by allowing them to be split by optional whitespaces/comments In fact it could simplify the lexer, with a very modest slowdown for the parser as it will read, and shift a few more tokens in an automata which is a bit larger in terms of total number of states.
If you don't do that, yes there programmers have to use explicit whitespace separators between ">" terminating an attribute and the "=" sign marking an assignment. This is minor because usual conventions recommend separating "=" in assignments for formatting the code.
This is then a very minor issue we can live with.
