少用符号，多写单词：Fun 语言语法的设计取舍

# 少用符号，多写单词：Fun 语言语法的设计取舍

先看一段能跑的 Fun：

```fun
fun classify(n)
  if n = 0 then
    ?. 'zero';
  elsif n < 0 then
    ?. 'negative';
  else
    ?. 'positive';
  end if;
end fun;

classify(0);
```

第一眼大概会卡在三处。

`if n = 0` 到底是赋值还是比较？`?.` 是什么，为什么不是 `print`？一个 `if` 为什么要有 `end if` 和分号两层收尾？

这三个问题看着像怪癖，其实正好对应三组取舍。Fun 的语法不是随手长成这样的。它背后有一条很稳定的线：**把复杂度从读代码的人身上，挪到写代码的人和实现语言的人身上。**

这篇文章就沿着这条线，把 Fun 语法里那些"为什么这样写"逐个拆开。每个设计点我都会说清楚三件事：它长什么样，为什么这么选，代价落在哪。最后一节专门列 Fun 不打算赢的战场。

---

## 先把坐标定下来

Fun 由张卫东在 2010 年设计并实现，前身是 2006 年的 Nuva，更早还有 2005 年的 TemplateScript。它的语法主干来自 Ada，异常处理来自 Delphi，一等函数和闭包接近 Lisp / JavaScript，`and` / `or` 的短路语义借自 Lua。这个组合本身就说明了它的定位：**一门用工业语言骨架写脚本的语言**。

大多数脚本语言在语法上走两条路。要么贴着 C 走，用花括号和分号，比如 JavaScript、PHP、Lua（Lua 稍微特殊一点）。要么贴着 Python 走，用缩进和冒号。Fun 两条都没走，它选了 Ada 那条更老、更啰嗦、也更少人走的路。

为什么？`overview.htm` 里有一句话，几乎就是全部答案：

> Fun 的语法非常简单清晰，主要语法来自 Ada 语言，为了简洁，适当的做了一些改变。语法主要从以下几个方面着重考虑，多用英文关键字，少用符号，易读易写易修改。

注意这句话的顺序。易读排第一，易写排第二，易改排第三。不是"易写"排第一。

一门语言如果把"写"放第一位，它会变得越来越短：箭头函数、链式调用、省略括号、隐式返回。写得快，读起来就费劲。Fun 反过来，它愿意让你多敲几个字母，换你半年后回来改代码时少猜几次。

但这里有个细节值得说清楚：Fun 优化的不是"新手第一次读"，而是"熟练的人反复读、反复改"。这两个目标经常冲突。新手第一次读，最想要的是熟悉感；熟练的人反复读，最想要的是无歧义。Fun 几乎每次都选后者。`?.` 就是最典型的例子，后面会单独讲。

还有一方也在付成本：实现者。很多语法糖看着不要钱，其实要在词法、文法、求值器里各加一段。Fun 的一个特点是，它非常不愿意让运行时为新语法买单。管道运算符就是样板，后面也会讲。

所以看 Fun 的语法，最好带着三个问题：

- 这条规则让谁少干活？
- 让谁多干活？
- 多出来的活，是一次性的，还是每次都要付？

---

## 一、能用单词就不用符号

Fun 里有一批 C 程序员很熟悉的运算，全部写成了英文单词：

```fun
var a = 17 div 5;      # 3，整除
var b = 17 mod 5;      # 2，取余
var c = not true;      # false
var d = a and b or c;  # 逻辑运算
var e = 6 bit and 3;   # 2，按位与
var f = 6 bit xor 3;   # 5
```

对比一下 C 系：

```c
int a = 17 / 5;
int b = 17 % 5;
int c = !true;
int d = a && b || c;
int e = 6 & 3;
int f = 6 ^ 3;
```

两边的信息量一样，但扫读时的感觉不同。`&&` 和 `||` 在密集的表达式里很容易看混，尤其是小字号和深色主题下。英文单词没有这个问题，因为它们的轮廓完全不同。`div` 和 `mod` 也不会像 `/` 和 `%` 那样，在一行里跟别的符号挤成一团。

但 Fun 并不是真的"反符号"。它反的是两类符号：一类是**可以写成词、而且写成词更清楚的**，另一类是**一个符号同时干好几件事的**。

看几个它保留的符号：

```fun
var s = 'abc' & 'def';   # 字符串拼接
var n = 1 + 2;           # 数字加法
var ok = name =~ /^A/;   # 正则匹配
var hit = 'a' in ['a', 'b'];
```

`&` 专门拼字符串，`+` 专门做数字加法。这一刀切得很干净。JavaScript 里 `+` 既能加数字又能拼字符串，`1 + '2'` 得到 `'12'`，这是多少 bug 的来源。Fun 把这两件事分给两个符号，你看到 `&` 就知道两边会被当成字符串，看到 `+` 就知道在做算术。运算符本身携带了类型信息。

同理，`=~` 是正则匹配，`in` 是集合成员判断，`<<` 和 `>>` 是移位。每个符号只负责一件事，而且这件事没有更短的单词可写。

这就是第一条取舍的完整版本：**不是符号越少越好，而是每个符号的责任越单一越好。** 能用单词表达且不损失精度的，用单词；必须用符号的，一个符号只干一件事。

代价也很直接：键盘敲得多了，代码行变长了，从 C 过来的人要重新建立肌肉记忆。但这个成本只付一次，读代码的成本每次都在付。

---

## 二、每个块都自己关门

Fun 没有单行 `if`。这是作者明确写过的决定：

> Fun 是纯粹的块结构语言，除了命令，其他全部是块结构（甚至取消了一行 if 的用法）。

所以下面这种写法在 Fun 里不存在：

```fun
# 不合法
if ok then ?. 'yes';
```

必须写成：

```fun
if ok then
  ?. 'yes';
end if;
```

第一眼看上去这是纯损失。四行干了一行的事。但它换来三样东西。

第一，**插入新语句永远不会改变语义**。C 里最经典的坑是：

```c
if (ok)
    do_something();
```

后来有人加了一行：

```c
if (ok)
    do_something();
    do_another_thing();   /* 这行其实已经不在 if 里了 */
```

Fun 根本不给你这个机会。只要进了 `then`，就是块；要加语句，只能加在块里。

第二，**收尾符自己说明自己关的是什么**。看这一段：

```fun
fun process(items)
  for item in items loop
    if item.valid then
      handle(item);
    end if;
  end loop;
end fun;
```

哪怕你从中间某一行开始读，看到 `end loop` 也知道它在关循环，看到 `end fun` 也知道它在关函数。C 系语言里只有一堆 `}`，深嵌套时得往上翻很久。Python 靠缩进，复制粘贴到别的地方很容易破坏结构。Fun 把结构写在了明面上。

第三，**错误恢复更容易**。少一个 `end if`，解析器知道在等什么；少一个 `}`，它只能猜。这个好处写代码的人感知不到，但 IDE、语法高亮、错误提示会直接受益。

这里还有一个小设计，官方 demo 里写得很清楚：

```fun
for i = 1 to 9 loop
  ? i;
end loop;

for i = 9 to 1 step -1 do
  ? i;
end do;
```

`for ... loop` 配 `end loop`，`for ... do` 配 `end do`，两种写法等价，但开头的词和结尾的词必须一致。`while` 也一样。这不是为了省事，而是为了让一对括号在视觉上对得上。你选了哪个开头，结尾就重复哪个词，不需要记"这个块到底该用什么收尾"。

代价当然有：代码变长，屏幕能放下的逻辑变少，写小型脚本时显得隆重。Fun 认了。它赌的是代码被读的次数远多于被写的次数。

还有一个不太显眼但很重要的收益：**块可以出现在任何地方，函数和类也不例外**。你可以在 `if` 里定义函数，在循环里定义类，作用域规则和变量完全一样。语法上没有"声明区"和"语句区"的区别，解析和心智模型都更统一。

---

## 三、赋值不配当表达式

Fun 里，赋值只能独立成一条语句：

```fun
var a = 1;
a = a + 1;
a += 2;
a -= 1;
a *= 2;
a &= 5;      # 字符串拼接赋值，a 变成 '45'
```

就这五种：`=`、`+=`、`-=`、`*=`、`&=`。没有 `++`，没有 `--`，没有 `/=`，也没有"在表达式里顺手赋个值"。

这条规则的影响比看起来大。

先说它消灭了什么。C 系语言里，下面这些写法都合法：

```c
while (n--) { ... }
if ((c = getchar()) != EOF) { ... }
a = b = c = 0;
foo(i++, i++);
```

它们都有一个共同点：**读代码的人必须在脑子里模拟求值顺序**。`i++` 到底什么时候加，`foo(i++, i++)` 的两个参数谁先算，不同语言、不同编译器、甚至不同优化级别都可能不一样。Fun 直接把这类问题从语法层面删掉了。

赋值是语句，意味着**一行以左值开头的代码，效果一定是修改这个左值**。它不会藏在条件里，不会藏在函数参数里，也不会作为另一个表达式的一部分。你读一行，就知道这一行改了什么状态。

再说它保留了什么。`+=` 这类复合赋值还在，因为 `a += 1` 的意图比 `a = a + 1` 更清楚，而且它仍然是语句，不产生值。字符串拼接也有专门的 `&=`，跟 `+` 和 `&` 的分工一致。

代价也很明显：写不了紧凑的指针遍历，写不了 `while (n--)` 这种一行循环，也没法用赋值表达式做"读一个值顺便判断是否成功"的惯用法。Fun 的处理方式是让你多写一行：

```fun
loop
  var line = read_line();
  exit when line = null;
  handle(line);
end loop;
```

这多出来的一行，换来的是这一段的求值顺序完全写在纸面上。

这条取舍和上一条是配套的。正因为语句和表达式分得开，第二条里的"块结构"才落得下来，第四条里的"一个等号"也才成立。

---

## 四、`=` 只有一个

在 Fun 里，表达式位置的 `=` 表示相等：

```fun
var a = 1;
?. a = 1;      # 输出 true
?. a != 2;     # 输出 true
?. a <> 2;     # 输出 true，!= 和 <> 等价
```

语句位置的 `=` 表示赋值：

```fun
a = 1;
```

同一个符号，两种含义，靠位置区分。

C 程序员看到这里大概会皱眉。`if (x = 1)` 在 C 里是赋值，在 Fun 里是比较。这不是笔误，是设计。Ada、Pascal、SQL 都这么干。它们把 `:=` 或 `=` 留给赋值，把 `=` 留给比较，Fun 更进一步，连 `:=` 都不要了，让语法位置来消歧。

这样做有两个好处。

第一，**`=` 和 `==` 的手误类别消失了**。C 系语言里，`if (x = 1)` 能编译，只是行为不对，这是初学者最常踩的坑之一。Fun 里你根本写不出"在条件里赋值"这件事，因为条件只能是表达式，而表达式里的 `=` 就是比较。

第二，**少记一个符号**。语言里的符号越少，读的时候认知负担越低。`!=` 和 `<>` 都接受，也是同一个思路：从 C 来的人写 `!=`，从 Pascal 来的人写 `<>`，两种都能跑，不必强迫谁改习惯。

代价是**第一眼的熟悉感**。从 C 系过来的人，看到 `if x = 1 then` 会本能地觉得哪里不对；看到 `?. a = 1;` 输出 `true`，更会觉得别扭。这个成本真实存在，而且不小。

但它是可以一次讲清的。一旦知道"语句位置是赋值，表达式位置是比较"，后面就不会再错。相比之下，C 的 `=` / `==` 问题是你每次手滑都可能中招，哪怕写了十年。

Fun 在这里选的不是"更符合直觉"，而是"更难写错"。这两件事经常不是一回事。

---

## 五、`?.` 是故意的

这是 Fun 最容易被记住、也最容易被吐槽的一处。

输出不叫 `print`，也没有括号。它是一组标点：

| 写法 | 含义 | 结尾追加 |
| --- | --- | --- |
| `? expr;` | 输出 | 什么都不加 |
| `?, expr;` | 输出 | 一个空格 |
| `?: expr;` | 输出 | 一个制表符 |
| `?. expr;` | 输出 | 一个换行 |

```fun
? 'a';
?, 'b';
?: 'c';
?. 'd';
```

输出结果是（`?:` 后面是一个制表符）：

```text
ab c	d
```

为什么要把最高频的语句压成两个字符？

我猜有几个原因叠在一起。

第一，**输出在脚本里实在太频繁了**。示例、调试、命令行工具，到处都是输出。`print('hello')` 是五个字母加一对括号，`?. 'hello'` 是两个标点加一个空格。一天写五十次输出，这个差距是能感觉到的。

第二，**它把 `print` 这个名字空出来了**。`?.` 是语法，不是函数，所以 `print` 可以是一个普通标识符，用户可以定义自己的 `print`，也可以把它当变量名。少一个关键字，就少一组命名冲突。

第三，**标点比单词更不占视觉带宽**。一段以 `?.` 开头的代码，扫过去的时候会形成一种节奏，像列表的项目符号。你很容易看出"这几行是在打日志"，而不需要逐字读 `print`。

第四，**四种结尾对应四种最常见的排版需求**。换行、空格、制表、原样，刚好覆盖了大部分输出场景，不用在字符串里手动拼 `\n` 和 `\t`。

但代价也很实在：**新手第一眼完全猜不出来**。`?` 在多数语言里是三目运算符的一部分，或者是可选标记，或者是错误传播。`?.` 看起来更像某种安全导航语法（比如 JavaScript 的可选链 `a?.b`）。Fun 把它反过来用作输出，这个冲突是真实存在的。

还有一个次生成本：**它依赖语法高亮**。在纯文本、diff、日志、邮件里，`?.` 很容易被看漏，尤其是在小字号下。`print` 不会。这是符号方案的固有弱点，Fun 用"高频"来抵消它，但没有完全消除。

我的看法是：这是全文里最值得争论的一处设计。它不符合"首次可读性"，但符合"熟练读者的扫读效率"。Fun 在这里明确站了后者。你可以不同意这个选择，但它不是随便定的，它和整门语言"少一个关键字、少一个函数、少一层括号"的方向是一致的。

顺带说一句，`?` 单独用的时候是不加任何结尾的：

```fun
? 'a';
? 'b';
?. '';
```

输出 `ab` 然后换行。这个用法在拼接进度条、逐字输出时很方便。

---

## 六、函数有五种长相

Fun 的函数是真正的一等公民，所以它的写法也分成了好几层。

最完整的是命名函数：

```fun
fun max(a, b)
  if a > b then
    result = a;
  else
    result = b;
  end if;
end fun;
```

`result` 是函数内置的返回值变量，函数结束时它的值就是返回值。也可以写 `@ = a;`，`@` 和 `result` 在这个位置是同一件事。当然，`return` 也支持：

```fun
fun min(a, b)
  if a < b then
    return a;
  else
    return b;
  end if;
end fun;
```

然后是匿名函数的几种形态，从重到轻：

```fun
var f1 = fun (a, b) { return a + b; };
var f2 =       (a, b) { return a + b; };
var f3 =              { ?. 'no args'; };
var f4 = a -> a * 2;
```

`fun (a, b) { ... }` 最完整，适合语句体。`(a, b) { ... }` 省掉 `fun`，适合回调。`{ ... }` 是零参匿名函数。`a -> a * 2` 是表达式体，适合一行能算完的纯函数。

再往下还有柯里化：

```fun
fun mul(bas, times)
  return bas * times;
end fun;

var m = fun mul(3);
?. m(4);      # 12
?. m(5);      # 15
```

`fun mul(3)` 不是调用 `mul`，而是把第一个参数固定成 `3`，返回一个新的单参函数。这个写法在小语言里不常见，但很好用。

为什么要有这么多层？因为函数的用途本来就不一样。命名函数是算法的骨架，需要名字、需要递归、需要被别处引用。回调是胶水，用完就扔。纯表达式函数是数据变换，越短越好。如果一门语言只有 `fun ... end fun`，写回调会非常吵；如果只有 lambda，写递归和命名又会别扭。

Fun 的选择是：**同一个概念，按使用场景给不同的重量级。** 你在写算法时用最重的形态，写回调时用最轻的形态，读者从形态就能大致判断这个函数的分量。

代价是风格不统一。同一个函数，在这里写成 `fun name(...) ... end fun`，在那里写成 `(x){...}`，新人需要一段时间才能建立"什么时候用哪个"的直觉。这需要风格约定来补，语法本身不强制。

还有一处冗余值得说：`result` / `@` 和 `return` 并存。为什么不全用 `return`？因为表达式体的 lambda 需要一个"最后的值就是返回值"的机制，`@ =` 比 `return` 更贴合这种写法。而 `return` 适合提前退出。两者分工不同，但确实增加了要记的东西。

---

## 七、数组、字典、对象、函数，都是同一个东西

Fun 的基础数据结构只有一种，官方叫"列表"，实际上它同时充当数组、关联数组、哈希表、字典、映射：

```fun
var arr = [1, 2, 3];
var map = [a: 1, b: 2, c: 3];

?. arr[0];      # 1
?. arr[-1];     # 3，负索引从末尾数
?. map.a;       # 1
?. map['b'];    # 2
```

迭代也是同一套：

```fun
for i in [1, 2, 3] loop
  ? i;
end loop;

for k: v in [a: 1, b: 2] do
  ?, k; ?, v;
end do;

for k: v, i in [a: 1, b: 2] do
  ?, k; ?, v; ?, i;
end do;
```

`for k: v, i` 一次拿到键、值、序号。这个设计在解析配置、遍历 JSON、处理查询结果时非常顺手。

再往下，对象也是表，函数也是表里的值：

```fun
class CA()
  var name = 'CA';

fun showName()
    ?. name;
  end fun;
end class;

var a = CA();
?. a.name;
a.showName();
```

你甚至可以用字符串键动态取成员：

```fun
?. a.'name';
```

为什么要把这么多概念压成一个？因为**概念越少，运行时越小，语义越统一**。Fun 的运行时大约 0.3 MB，没有外部依赖，这和"只有一种数据结构"是直接相关的。序列化也统一：一个表可以直接变成 JSON，反过来也一样。

代价是**没有形状**。Fun 没有 `struct`，没有记录类型，没有编译期的字段检查。一个表里有什么键，只有运行时才知道。拼错字段名不会在写的时候报错，而是在取到 `null` 的时候才暴露。这是动态类型的通用问题，但在"一切皆表"的设计下会更明显。

还有一个代价是**性能上的取舍**。通用表为了同时支持数组和字典，内部结构比纯数组或纯哈希复杂，密集数值计算不如专用容器快。Fun 的应对是 JIT 和 C/汇编内联，而不是把基础数据结构拆成好几套。这是一条很明确的路线：**用底层能力解决性能，不用语法复杂度解决性能。**

---

## 八、`@` 是个筐

`@` 在 Fun 里有好几个身份：

```fun
fun f()
  @ = 42;          # 1. 函数返回值
end fun;

case cmd is
  when 'hello' do
    ?. @ & ', world!';   # 2. case 的匹配值
end case;

try
  raise 'boom';
except
  ?. 'caught: ' & @;     # 3. except 捕获到的异常
end try;

var t = @'2026-11-01';   # 4. 时间字面量前缀
```

而且 `@` 本身还能作为内置变量名出现，所以它更像一个特殊的名字，而不是一个严格意义上的保留字。

这套复用的逻辑是：**`@` 永远表示"当前上下文里的那个值"**。在函数里是返回值，在 `case` 里是被匹配的值，在 `except` 里是异常。语义上有一条线，只是每条线的具体所指不同。

好处是省关键字。你不需要 `result`、`matched_value`、`exception` 三个名字，一个 `@` 全包了。代码看起来也更轻。

坏处是**读代码时必须知道自己在哪个块里**。单独看 `?. @ & ', world!';` 这一行，你不知道 `@` 是什么，得往上找最近的 `case` 或 `except` 或 `fun`。这对局部阅读不友好，对 grep 也不友好：你没法搜 `@` 来找所有返回值。

这是一个典型的"写得省，读得费"的取舍。Fun 在这里选的是写和省，而且赌你大部分时候是在块的上下文里读代码，而不是孤立地看一行。

类似的还有 `null` 和 `nil` 都接受。它们都表示空值，从不同语言来的人可以用自己习惯的拼写。这是纯粹的善意，代价是同一个概念有两个名字，代码库里可能混着用。

---

## 九、点号后面可以接符号

Fun 允许用字符串键定义运算符方法：

```fun
class Number(me)
  this['#'] = you -> (me + you) * me * you;
end class;

var $ = Number(2);
?. $ .# 3;      # 调用自定义运算符 #
?. $[1](3);     # 通过索引取方法再调用
```

`this['#']` 把 `#` 这个符号注册成方法，之后 `$ .# 3` 就等价于调用它。`.` 后面可以接的符号不止 `#`，文法里列了一串，包括 `~ ! # % ^ & * + = \ | < > / ?`。

这个设计的妙处在于：**自定义运算符不需要改文法**。语言本身不认识 `#` 作为运算符，它只认识"点号后面跟一个符号"这个模式，剩下的交给表查找。于是用户可以用任意符号扩展类型的行为，而解析器一行都不用改。

代价是**可读性依赖约定**。`$ .# 3` 对不熟悉这段代码的人来说，几乎不可读。它也太容易和普通的方法调用混在一起。Fun 的官方说法是"支持少量的运算符重载"，这个"少量"很重要：它给了你扩展的能力，但不鼓励你把整个类型系统建成符号迷宫。

还有一个小细节：`a.'name'` 可以用字符串键取成员，和 `a.name` 等价。这让"动态字段名"写起来很自然，比如：

```fun
?. this['Rpc_' & method];
```

拼接出来的方法名可以直接调用。这种写法在实现 RPC 分发、插件表、命令路由时非常省事。代价还是同一个：静态工具没法跟踪，重构时不敢随便改名。

---

## 十、管道是语法糖，而且只是语法糖

管道在 Fun 里长这样：

```fun
var f = a -> a * 2;
var g = a -> a + 3;

?. g(f(1 + 2) + 3);    # 12
?. 1 + 2 | f + 3 | g;  # 12
```

`|` 把左边的值作为实参，递给右边的函数。`1 + 2 | f + 3 | g` 读作：先算 `1 + 2`，把结果给 `f`，再加 `3`，把结果给 `g`。

重点不在它好用，而在它**几乎没有成本**。Fun 的实现里，管道只在词法加一个 token、文法加两条归约规则。解析阶段就把它归约成一次普通的函数调用，运行时的虚拟机、执行器、类型系统完全不知道"管道"的存在。

这件事值得单独拎出来说，因为它体现了一种很克制的设计态度：**能不加执行语义就不加。** 很多语言给管道单独设计求值逻辑，Fun 没有。它只是把"值在前、函数在后"的写法，调整成适合从左往右读的顺序，剩下的全部复用已有的调用机制。

我在另一篇《Fun 的管道：一个纯语法糖运算符》里拆过它的实现，这里不重复。放在这篇里，它是一条取舍的样板：**语法糖的极限，是让运行时完全感知不到它。**

代价是管道只能做"把左边的值传给右边的函数"这一件事。它不支持多参数占位，不支持把值插到参数列表中间，也不支持反向管道。想要更复杂的组合，还是得写嵌套调用或者中间变量。Fun 没有为了管道的表达力去增加运行时概念，这个边界划得很清楚。

---

## 十一、正则和时间配了字面量

脚本语言的大部分工作在处理文本和时间，所以 Fun 把它们做成了字面量，而不是库函数。

正则有三种写法：

```fun
var re1 = /(\d+)-(\d+)/;
var re2 = %(\d+)/(\d+)%;          # 内容里有 / 时换分隔符
var re3 = $' \d+ \s* - \s* \d+ 'x;  # 带空格和注释的扩展模式
```

匹配用 `=~`，不匹配用 `!~`：

```fun
var m = '2026-11-01' =~ /(\d+)-(\d+)-(\d+)/;
?. m.groups(1);    # 2026
```

时间用 `@` 前缀：

```fun
var t = @'2026-11-01 16:40:00';
```

字符串有三种引号：

```fun
var a = 'it''s';        # 单引号，内部单引号双写
var b = "say ""hi""";   # 双引号，同理
var c = `多行
字符串`;                # 反引号，可跨行
```

为什么要把这些做成字面量？因为它们是脚本里出现频率最高的东西。正则如果每次都要 `new RegExp("...")`，转义会把代码毁掉；时间如果每次都要解析字符串，样例代码会变得很长。字面量让这些操作在视觉上成为"一个值"，而不是"一次函数调用"。

代价是**词法分析变复杂了**。`/` 既可能是除法，也可能是正则的开始；`@` 既可能是返回值、异常、匹配值，也可能是时间字面量的前缀；`%` 既是正则的备用分隔符，又是可以重载的运算符符号。词法器必须靠上下文判断，这会让文法变得不那么规则，也会让第三方工具（编辑器、语法高亮、格式化器）更难写。

Fun 愿意付这个成本，因为它的第一使用场景是写脚本，不是写编译器。脚本里正则和时间的密度，远高于算术表达式里 `/` 的密度。这是一个按使用频率分配复杂度的决定。

顺带说一句题外话：这些字面量也意味着 Fun 的源码不能随便用别的语言的词法器来高亮。想给 Fun 写编辑器支持，得老老实实实现它的上下文规则。这是"语法有特色"的隐性账单。

---

## 十二、几处借来的小聪明

有几条语义不是 Fun 原创的，但借得很值，各自只占一小块，不改变整体风格。

**`and` / `or` 返回操作数，不是布尔值。** 这来自 Lua：

```fun
var name = user.name or 'anonymous';
```

如果 `user.name` 是真值，整个表达式就是它；否则是 `'anonymous'`。这让"取默认值"不需要三元运算符，也不需要 `if`。代价是从强类型语言来的人会不习惯：`a and b` 的结果类型可能不是布尔。Fun 没有为此加限制，它相信你知道自己在做什么。

**`exit when` / `next when` 守卫。** 这是 Ada / Eiffel 血统里很好的一件东西：

```fun
loop
  exit when i > 9;
  next when i mod 2 = 1;
  ? i;
  i += 1;
end loop;
```

它把"什么时候退出"写在循环开头，而不是嵌在 `if` 里。少一层缩进，读的时候也更容易先看到边界条件。这比 `break` / `continue` 加 `if` 的组合更直白。

**`try` / `except` / `finally` 可以同时用。** 这来自 Delphi，但 Fun 做了增强。很多语言的 `try` 要么配 `catch`，要么配 `finally`，Fun 允许两个都写：

```fun
try
  ? 'working';
  raise 'boom';
except
  ?. 'caught: ' & @;
finally
  ?. 'cleanup';
end try;
```

异常值通过 `@` 取到。没有 `on E: Exception do` 那种类型分支，因为 Fun 是动态类型，需要判断的时候用 `case` 就够了。这是"去掉静态类型带来的语法负担"的一个直接例子。

**单继承。** Fun 只支持基于类的单继承：

```fun
class CB = CA()
  name = 'CB';
end class;
```

没有多继承，没有 mixin，没有复杂的 MRO。方法查找就是沿着一条链往上走，心智模型极其简单。代价是你不能用继承组合多个能力，得用包含或者表来拼。对一门小语言来说，这个取舍很划算：多继承带来的复杂度，远大于它解决的问题。

**中文关键字包。** Fun 支持把关键字映射成中文，`函数`、`如果`、`则`、`结束` 这一套。这是一个本地化实验，官方并不提倡用中文写正式代码，因为生态、工具、协作都假设英文关键字。但它存在本身说明了一件事：关键字是词法层的东西，换一套词并不难。真正难的是让整个生态跟着换。

这些小语义各自都很小，加起来却让 Fun 写起来比它的语法看起来要顺手。它们没有破坏整体风格，因为每一条都只影响一个局部，而且都能用一句话说清。

---

## 代价清单

把上面的取舍收进一张表，看得更清楚。

| 设计点 | 常见做法 | Fun 的做法 | 换来了什么 | 放弃了什么 |
| --- | --- | --- | --- | --- |
| 逻辑与位运算 | `&&` `\|\|` `!` `&` `\|` `^` | `and` `or` `not` `bit and` | 扫读时轮廓清楚，符号不撞车 | 键盘输入量 |
| 块结构 | `{}` 或缩进 | `if ... end if`，无单行 if | 插入语句不改语义，收尾自解释 | 代码行数 |
| 赋值 | 表达式，可嵌套 | 只能独立成句 | 求值顺序显式，无隐藏副作用 | 紧凑写法 |
| 相等 | `==` | `=` | 消灭 `=` / `==` 手误 | C 系用户的熟悉感 |
| 输出 | `print(...)` | `?.` `?,` `?:` `?` | 最高频操作最短，省一个关键字 | 首次可读性，依赖高亮 |
| 函数 | 一种或两种形态 | 命名块 + 四种匿名形态 + 柯里化 | 按场景选最轻的写法 | 风格统一性 |
| 数据结构 | 数组、字典、结构体分开 | 一切皆表 | 运行时小，语义统一，序列化简单 | 静态形状，专用性能 |
| 空值 | `null` 或 `nil` | 两个都收 | 迁移友好 | 一致性 |
| 上下文值 | 多个专用关键字 | 一个 `@` | 少关键字，写得短 | 局部可读性，可搜索性 |
| 扩展运算符 | 改文法或固定集合 | `.` 后接任意符号 | 用户可扩展，解析器不改 | 可读性依赖约定 |
| 管道 | 独立求值语义 | 纯语法糖，解析期归约 | 运行时零成本 | 表达力有限 |
| 正则/时间 | 库函数 | 字面量 | 写起来短，视觉上是值 | 词法复杂度，工具支持难 |
| 默认值 | 三元或 `if` | `and` / `or` 返回操作数 | 一行取默认值 | 结果类型不总是布尔 |
| 继承 | 多继承或 mixin | 单继承 | 方法查找极简 | 组合能力 |

---

## Fun 不打算赢的战场

写到这里，该说的好处和代价都说了。还有一件事需要挑明：Fun 的语法不是在所有维度上都更好，它是**在某些维度上明确放弃竞争**。

**静态检查。** 动态类型加一切皆表，意味着字段名拼错、参数类型不对、返回值形状变化，都要到运行时才发现。Fun 没有类型标注，也没有计划加。它换来的是写脚本时的零仪式感。这个交换对脚本成立，对大型长期项目不成立。

**大型多人协作。** 英文关键字和显式块结构对协作是友好的，但动态类型和"一切皆表"不是。一个几十人的代码库需要接口契约、需要静态分析、需要 IDE 跳转，这些都不是 Fun 的强项。

**工具链生态。** Fun 的语法有太多上下文相关的规则：`/` 是除法还是正则，`@` 是返回值还是异常还是时间，`.` 后面跟符号是什么意思。这些对人类读者是可控的，对通用工具是麻烦的。编辑器支持、格式化器、linter，都得专门为它写。

**新人第一眼。** `?.`、`@`、`$ .# 3` 这些写法，第一次看都需要解释。Fun 没有为降低第一眼门槛做优化，它优化的是第十眼、第一百眼。这是一个明确的赌注，不是疏忽。

**性能。** 这篇不聊性能，但顺带说一句：Fun 的性能路线是 JIT 和内联 C/汇编，不是靠语法把代码写得更"接近机器"。语法层面的选择基本不为性能服务。

把这几条摆出来，不是为了唱衰，而是为了让取舍完整。一门语言的设计文档如果只讲优点，读的人反而不知道该不该用。Fun 适合的是：一个人或小团队、以文本和系统集成为主、需要快速写工具、能接受运行期错误的场景。它的语法就是为这个场景长的。

---

## 结语：复杂度守恒

语法设计里有一条近似守恒的规律：**复杂度不会消失，只会换个人承担。**

C 把复杂度放在读者身上，`*`、`&`、`->`、`++` 混在一行里，读的人自己解析。Python 把复杂度放在格式和运行时上，缩进即结构，代价是复制粘贴和隐式类型。Go 把复杂度放在写的人身上，错误要一行行写。Rust 把复杂度放在编译器身上，生命周期要显式标注。

Fun 的选择是：**让读者轻松，让写者多敲几个字母，让实现者多写几条文法规则。**

所以它用 `end if` 而不是 `}`，用 `and` 而不是 `&&`，用 `=` 而不是 `==`，用 `?.` 而不是 `print`。每一条都在把成本从"每一次阅读"挪到"一次性的书写"或者"一次性的实现"。

这些选择不总是对的。`?.` 对新手不友好，`@` 的上下文重载让局部阅读变难，一切皆表让静态检查无从下手。但它们是自洽的：你很难只拿走其中一条而不接受其他几条。你享受了 `=` 只有一个的好处，就得接受语句和表达式分离；你享受了 `?.` 的短，就得接受它的学习曲线；你享受了运行时小，就得接受没有静态形状。

一门语言的语法，说到底是在回答一个问题：**你希望谁在什么时候付出代价。** Fun 的答案写在了它的每一行代码里：读的人现在轻松，写的人多敲几下，实现的人多写几条文法。这个答案不一定适合你，但它是一条想清楚了的答案。

---

*本文的语法示例取自 `demo/` 下的官方示例，并与 `fun.ebnf`、`ebnf.xhtml`、`overview.htm` 核对。示例中的 `#` 注释、`?.` 输出和 `end X` 收尾均为 Fun 原生写法。*