R解析器为何将do.call参数中的knitr::kable解析为SYMBOL而非SYMBOL_FUNCTION_CALL？

Great question! Let’s break down exactly why R’s parser treats kable this way:

• Syntactic context determines token type
  R’s parser assigns token types based on how code is structured, not what the code does at runtime. The SYMBOL_FUNCTION_CALL token is only used for symbols that are directly invoked as functions. For example, in your code, do.call gets this token because it’s the function being called right there.

• knitr::kable is an argument, not a direct call
  When you pass knitr::kable as the first argument to do.call, the parser sees it as a nested expression (made up of knitr (SYMBOL_PACKAGE), :: (NS_GET), and kable (SYMBOL)), not a function being executed. Since kable isn’t the starting point of a function call in this context, it doesn’t get the SYMBOL_FUNCTION_CALL label.

• Even direct pkg::fun() uses different tokens
  As a quick side note: if you wrote knitr::kable(my_data), kable still wouldn’t be marked as SYMBOL_FUNCTION_CALL. That’s because pkg::fun is syntactic sugar for calling the :: function (yes, :: is a real function!). In that case, :: would be the SYMBOL_FUNCTION_CALL, with knitr and kable as its SYMBOL arguments.

Looking at your parsed output confirms this behavior:

• The do.call token (line 1) is correctly tagged as SYMBOL_FUNCTION_CALL—it’s the function being invoked.
• The knitr::kable expression (lines 4-6) is split into three separate tokens, with kable as a plain SYMBOL because it’s not the function being called in this syntactic position.

To sum it up: the parser doesn’t check if a symbol refers to a function at runtime—it only cares about where the symbol appears in the code’s structure. That’s why kable gets the SYMBOL tag here instead of SYMBOL_FUNCTION_CALL.

内容的提问来源于stack exchange，提问作者yonicd