Great catch! Love it when folks approach a challenge critically.
I didn’t consider that case initially, but I think it’s all right. Let’s step back a bit: remember we chose to interpret a(4) as a call to a() with argument 4. We could interpret s i n ( 4 5 ) in two ways: sin() of 45 [function call] or s*i*n*45 [implicit multiplication]. The latter is forbidden by our rules, though, so it all works out. Whether that’s what the user intended or not I’d a different matter, one which we can help in by educating the user properly.
Admittedly, there are lots more possible malformed inputs that could cause headaches. But I stated in the article that we’re “trusting” the user to provide valid input, so we can focus on the tokenizing. However, implementing validation is another interesting challenge that I plan to take on soon enough.