Fun 的管道：一个纯语法糖运算符

很多语言给管道运算符单独设计了执行语义,要写专门的求值代码。Fun 里它却只活在文法里。这篇用一个很小的切口拆开看:一门语言要支持 `a | b` 这样的管道写法,最小能做到多省。

## 先看它是什么

先感受一下要讨论的语法。Fun 里函数是一等公民,很多"把结果一步步递给下一个函数"的代码可以写成管道。仓库自带的高层示例(README 与 `fun/demos/benchmarks/test-high-level-language.fun`)里有这样一对等价的写法:

```fun
var f = a -> a * 2;
var g = a -> a + 3;
?. g(f(1 + 2) + 3);   # 12,嵌套调用从内往外写
?. 1 + 2 | f + 3 | g; # 12,同一个结果,用管道从左往右写
```

`|` 把左边的中间结果作为实参,递给它右边的函数。上面两个 `?.` 打出同样的 12,只是前者一层层括号往外包,后者摊平了、顺着数据流动的方向从左往右读。语法很顺手,可你猜这背后要为它写多少代码?

## 它藏在文法里,不在运行时里

如果去 `src/parse/bnf` 里搜管道,会搜到什么?答案是三处,全部在"描述语言长什么样"的文法里,而不是在"负责执行"的代码里:

1. **lex 里加一个 token**(`lex.l`):把管道符号 `|` 认出来。

```text
opPipe  "|"
```

2. **yacc 里声明它的优先级**(`yacc.y`):`%left opPipe`,让管道比几乎所有的二元运算符都"松",这样一整条链能自然串联、不打架。

3. **yacc 里加两条归约规则**(`yacc.y`):

```text
Exp opPipe VarExp   # 右边是一个名字(函数/变量引用)
Exp opPipe FunCall  # 右边是一个调用
```

真正的机关在第 3 处。两条规则的动作是同一个:把 `a | b` 归约成一次函数调用——用 `CreateValues` 把左边的 `a` 包成参数表,再交给 `CreateFunExp` 去构造一个 CFunc 调用节点。翻译成大白话就是:**"把左边这个值,作为实参,去调用右边这个函数。"** 这跟手写 `b(a)` 是同一件事。

## 解析阶段就被拆穿,运行时只看到一次普通调用

因为管道在归约那一步就变成了一个函数调用节点,所以再往下,虚拟机、执行器、类型系统……全都感知不到"管道"的存在。解释器真正拿到的只是一句普通的 `f(值)`,里面没有任何一条为管道新写的求值分支。

这正是它省到极致的原因:**一切在解析阶段就结束了**。运行时不需要认识管道。

## 为什么能这么省

根源在于 Fun 的调用模型足够简单直接:函数是一等公民,"把一个值传给一个函数去调用"本来就是这门语言最基础的能力。既然"调用"已经把"传值给函数"这件事做全了,那么管道要做的,仅仅是**把写法上"值在前、函数在后"的顺序,调整成适合从左往右读的顺序**。剩下的全部复用既有机制,一行新的执行代码都不用写。

## 小结

管道运算符在 Fun 里是一个教科书式的纯语法糖:

- 运行时零改动,没有新增求值逻辑;
- 词法加一个 token,文法加两条归约;
- 归约时把左边值塞进函数调用,余下交给已有的调用机制。

当一门语言把核心能力收敛得足够干净时,很多"看起来很厉害的特性",其实只是语法层的一点巧劲。管道就是其中一个:它没有发明新的执行语义,只是让已有的"调用"换了一种更顺手的写法。