nil 加 1，等于几

# nil 加 1，等于几

一句话总结: 把 Fun 解释器移植到 Linux(FPC 构建)后,`a[b] += 1` 在键不存在时会静默什么都不做。根因不在赋值,而在算术:Fun 把 `+ - * / div mod` 交给了 Pascal 的 Variant,而 FPC 对"空值"采用**传播**语义,Delphi/COM 采用**当零**语义。同一门语言因此自相矛盾:`x = 0` 为真,`x + 1` 却是 nil。

## 一个静默失效的赋值

把解释器搬上 Linux 之后,一类问题冒了出来:某些累加计数悄悄失效。

```fun
var count = new [];
var name = 'Ref';

count[name] += 1;      # 应该把计数器加 1
?. count[name];        # 修复前: 还是 nil,值根本没变
```

Fun 里的 `+=` 会被脱糖成"读—算—写",上面的语句等价于:

```fun
count[name] = count[name] + 1;
```

键 `name` 不存在,读出来是 nil;`nil + 1` 按常理应该得 1,可结果仍是 nil,写回去自然什么都没变。所以真正有问题的不是赋值,而是那次加法。

## 缺失的值,到底是什么

Fun 里没有单独的"未定义"类型。未初始化的变量、缺失的集合键、返回空值的函数结果,底层都是同一个东西:`VType = varEmpty`(空值),或者它的近亲 `varNull`。

而 Fun 自己**对"空"的解释本来就是"当零"**。核心里的 `isNull` 是宽松的:空值、空串、数值 0 都算 nil。于是同一段脚本里会出现这样一组结果:

```fun
var x;          # 未初始化
?. x = 0;       # true
?. x = nil;     # true
?. x + 1;       # 修复前: nil   ★
?. 'a' + x;     # 修复前: nil   ★
?. x & 'a';     # 'a'  (& 是 Fun 自己的拼接,不受影响)
```

`x = 0` 为真,`x + 1` 却是 nil。这个自相矛盾本身就是 bug 的证明:不需要对比别的平台,语言内部就对不上。

## 算术为什么特殊

Fun 的运算符大多是自己实现的:比较(`=` `<` `>`)、字符串拼接 `&`、位运算、布尔运算,都在解释器里逐条写死。唯独 `+ - * / div mod` 这六个,直接把运算交给宿主 Pascal 的 Variant:

```pascal
C01: begin e1^ := e1^ + e2^; end;   // +
C02: begin e1^ := e1^ - e2^; end;   // -
C03: begin e1^ := e1^ * e2^; end;   // *
C04: begin e1^ := e1^ / e2^; end;   // /
C05: begin e1^ := e1^ div e2^; end; // div
C06: begin e1^ := e1^ mod e2^; end; // mod
```

在 Delphi / Windows 上这没问题:Delphi 的 Variant 来自 COM/OLE,那里的 Empty 在算术里被当作 0 或空串。但 FPC 的 RTL 是另一套实现,它对 Empty 采用**传播**语义。FPC 源码 `variants.pp` 里的公共类型表让 Empty 与任何类型相遇都得到 `ctEmpty`,算术入口遇到它就把结果直接清成 Empty:

```pascal
ctEmpty:
  case OpCode of
    opDivide:                 Error(reZeroDivide);
    opIntDivide, opModulus:   Error(reDivByZero);
  else
    DoVarClear(TVarData(Left));     // 结果清成 Empty,不报错、也不取 0
  end;
```

实测下来是:Empty 加 1 得 Empty,减 1、乘 2 也还是 Empty;而 `Empty / 2` 甚至抛 `Runtime error 200`(除零)。最麻烦的是 Empty 一旦产生就会**继续向下传播**——这就是"静默失效"的来源。

Fun 的比较说"空值等于零",Fun 的算术(在 FPC 上)却说"空值吃掉一切"。语言自己跟自己打架。

## 修在哪里

根上的修法:在 `src/core/calc.inc` 的 `C01..C06` 里,把运算交给 RTL 之前,先把 **Empty/Null** 操作数规范成该运算期待的零值:

- `- * / div mod`:空值 → 整数 0;
- `+`:看另一侧——另一侧是字符串就给 `''`,否则给 0(与 RTL 自己"同为字符串才拼接、否则走数值"的规则一致)。

只动真正的 Empty/Null;数值 0 和空串保持原样,所以既有行为一律不变。

这里有一个实现上的陷阱值得记下:`e1` 是累加器,运算结果要写回它,可以就地规范化;但 `e2` 可能是**活变量**——`1 + x` 里的 `x` 就直接指向变量存储。所以对 `e2` 必须用规范化后的临时副本,绝不能写回,否则执行 `1 + x` 会顺手把 `x` 清成 0。修复后的效果:

| 表达式 | 修复前 | 修复后 |
| --- | --- | --- |
| `x + 1` / `1 + x` | nil | `1` |
| `x + 'a'` / `'a' + x` | nil | `'a'` |
| `x - 1` | nil | `-1` |
| `x * 2` / `x div 2` / `x mod 2` | nil | `0` |
| `x / 2` | Runtime error 200 | `0` |
| `a[b] += 1`(键缺失) | 仍是 nil | `1` |
| `1 + x` 之后再读 `x` | — | 仍为 nil(未被就地修改) |

## 语义补丁,不该拖慢另一条路

第一版把规范化做在了所有平台上,于是 Delphi 构建的算术热路径平白多了一次函数调用和一次 Variant 拷贝,实测慢了约 10%(300 万次混合算术,5.45s → 6.01s)。

但这份规范化只在 FPC 上才有意义:Delphi/COM 本来就当零,根本不需要。于是把它收紧成两步:先用一次 `VType` 比较判断有没有空值,没有就直接走原来的 `e1^ := e1^ op e2^`,有才进慢路径;再用 `{$IfDef FPC}` 把整段包起来,Delphi 构建回到修复前一模一样的代码。性能回到 5.58s,代价只剩两次类型比较。

一个只在 Linux 上出现的移植陷阱,修好之后,Windows 侧一行没动。

## 验证

本地回归 62/62,默认构建与 `-dCalcOpt` 快路径各跑一遍。再把全部 demo/test/ffi 脚本的输出与修复前的基线二进制做逐字节差分:除一条按新语义更新的语言语义用例之外,完全一致。

还有一个诚实的边界:Windows 上用 FPC 交叉编译出来的构建,行为是否和本机的 FPC 3.2.2 一致,尚未确认。若一致,它同样受益于这次修复;这需要在 Windows 机上跑一次才能定性。

## 一句话总结

缺失值不是一种值,但它更不该是算术里的黑洞。比较和算术必须对"空"说同一句话,这门语言才自洽。