It's doing longest token matching, and "+1" is a longer token than "+",
so "+1" wins.
I would deal with this by treating the signs as unary operators.
I could enhance the Scanless interface so that G0 takes into account
which tokens are expected, and will therefore not accept a number after
the first one. But there's an efficiency cost, depending on how I do
that -- the unary operator approach is fast, given the current
implementation. And the Scanless if's current approach is consistent
with the way current lexers do it -- they are (unless you get into state
hacks) clueless about the upper layer's expectations.
-- jeffrey