R语言中为何可创建点(.)开头对象却不能创建下划线(_)开头对象

1. 下划线开头的对象无法创建的核心原因 #

R的词法解析体系承袭自1970年代贝尔实验室开发的S语言。早期S语言并未将<-作为标准赋值语法，而是将下划线符号作为赋值运算符使用，语义等价于现在的赋值操作，即表达式x _ value表示将value赋值给对象x。

这个历史设计带来的直接后果是：解析器一旦在表达式的起始位置识别到下划线，会优先按照赋值运算符的逻辑做解析，不会将其作为对象名的起始字符处理。如果用户直接输入_var = 1尝试创建对象，解析器会将开头的下划线识别为赋值符，后续的语法片段无法匹配合法表达式结构，直接抛出语法错误。

后续R虽然扩展了标识符规则，允许下划线出现在对象名的中段（如my_var是完全合法的命名），但并未修改解析器对起始位置下划线的歧义处理逻辑，因此下划线开头的对象始终无法正常创建。

2. 点开头的对象可正常创建的设计初衷 #

R允许点开头的对象正常创建，同样来自对S语言设计的沿袭。在R尚未具备完善的包命名空间隔离机制的早期版本，点开头的命名被约定为包内部使用、不对普通用户公开的私有对象，和通用编程体系里单下划线前缀的私有标记作用一致。

配套的交互设计包括：ls()函数默认不展示工作区中点开头的对象，必须显式传入all.names = TRUE参数才能看到这类对象，从交互层面避免包内部的临时、实现类对象干扰用户的常用对象列表。这类点开头的对象可以完成正常的赋值、读取、修改操作，不存在功能上的限制，仅靠命名约定做使用边界的提示。

3. 正式命名规则与设计逻辑总结 #

明确的合法命名边界 #

• 对象名的起始字符仅允许两种：大小写字母、英文点号；数字、下划线、其他特殊字符均不允许作为起始位
• 起始字符之后的内容，可自由组合字母、数字、英文点、下划线，无固定长度限制
• 存在特殊语法优先级例外：点号后直接跟随数字的命名（如.123）会被解析器识别为浮点数字面量，不视为合法对象名

可直接在控制台验证的命名示例：

# 合法命名
my_var = 1       # 下划线在中段，合法
.config = list() # 点开头，合法
obj.2 = "test"   # 点在中段，合法

# 非法命名
_temp = 1        # 下划线开头，触发语法错误
1st_obj = 1      # 数字开头，触发语法错误
.1obj = 1        # 点后直接跟数字，被解析为数字0.1，触发语法错误

设计逻辑的两层核心来源 #

• 历史兼容：R没有完全抛弃S语言的词法解析框架，早期将下划线作为赋值运算符的设计遗留了天然语法歧义，为避免解析冲突，直接将开头的下划线排除在合法命名范围外，从根源上消除歧义可能
• 实用性平衡：点开头的命名规则不需要额外引入新的语法关键字，就能实现“用户层对象/内部实现对象”的层级隔离；同时配合默认隐藏的列表展示逻辑，减少日常交互时的信息冗余，平衡了语法灵活性和交互简洁性。

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