if you can't figure out a good function name, look for a design problem.

That seems like sound advice. (Heck, any reason to look for a design problem is a good one.) Even though it makes a good rule of thumb, like most advice, it could be hazardous if followed in every instance. Sometimes an awkward function is the right one. Code is not natural language afterall. Consider that, if you allow your spoken language to have too great an influence on how you code, you may be artificially limiting your design choices right from the start.

I think it is best when code approximates a written description. It needn't actually read like one. Frankly, your use of "_are_the_" in a subroutine name makes me cringe. Why? Because words of that nature could crop up in lots of subroutine names and when that happens your eye has to work harder to differentiate them.

Instead of tokens_are_the_same(), I would be inclined to use something like tokens_same(). I might call it tokens_equal() or tokens_equivalent() depending on what it actually did. (I think 'same' indicates that two references refer to the same memory, 'equal' indicates that the values are the same, and 'equivalent' indicates that two values have the same type. For instance, two STRING tokens might be equivalent but not necessarily equal or the same.) In general, I think good subroutine names are as short and dense with meaning as possible without being cryptic.

-sauoq
"My two cents aren't worth a dime.";