FD：一种自己描述自己的数据格式

# FD：一种自己描述自己的数据格式

## 它长什么样

FD 用缩进表达层级，空格分隔键和值，和 JSON 存的是同一份数据：

```text
person
  name 张卫东
  age 46
  skills
    - pascal
    - c
    - fun
```

等价的 JSON 只有一行：

```json
{"person": {"name": "张卫东", "age": 46, "skills": ["pascal", "c", "fun"]}}
```

没有大括号和逗号，键名默认不写引号，数组用 `-` 起头。结构还是 JSON 的结构，读起来却像缩进文本。

## 规范也是 FD 写的

`fun/lib/fd.fd` 这份文件就是 FD 格式的规范，而它本身用 FD 写成。开头两行是整行注释，随后是嵌套的键：

```text
#!FD格式规范
# 为整行注释

文件 FD格式规范自描述文件
简介 兼容JSON结构的类MD格式
目标 人类和机器包括AI友好

FD_specification
  basic_syntax
    键值对 键与值至少一个空格
    嵌套
      子键 子行缩进
      数组
        - 元素1
```

规范用被规范的语言写出来，不只是炫技。同一份文件既是给人看的文档，又是可被解析的数据，工具只要理解 FD 就够了，不用为文档再维护一套语法。

## 文法也是 FD 写的，解析器现场编译

更关键的一步在解析器。`fun/lib/fd.bnf.fd` 是 FD 的文法，它本身也是一份 FD 文件：

```text
# bnf of fd
@name    Row

`lib-fd.fun` 没有把这套文法手写成递归下降，而是交给 `lib-bnf` 的 `CBNF` 在运行时编译：

```fun
use ':fd.bnf.fd' as rules;
rules = rules.getJson(fd: true);   // 文法文件本身就是 FD,用 FD 解析

var cbcb = CBNF(rules, dup: 0);
...
result = cbcb.parse(s, actions);
```

先把 `fd.bnf.fd` 按 FD 读成规则表，再把规则表编译成匹配器，最后用它解析任意 FD 文本；`actions` 回调负责在匹配过程中把结果拼回语法树。于是"解析 FD"这件事，靠的是一份用 FD 写成的文法——环在这里合上。整份解析器不到 120 行，其中一大半还是那段拼树的归约逻辑。

## 语法要点

规范里写着几条不显眼但常用的规则：

- **缩进**：两个空格算一层，相对深度 +1；`>>>` 表示绝对深度 3，`3>` 也是绝对深度 3。优先级依次是 `数字>`、`>` 重复、两个空格。
- **标识符**：默认无引号；含空格的键要写成 `"带 空格 的标识符"`。键不能有空格，值可以有。
- **值类型**：数字(含 `-3.14`、`-2.7e-6`)、常量 `true`/`false`/`null`/`[]`/`{}`，以及字符串。
- **字符串**：双引号、单引号、反引号三种引号，都支持多行和内部双写转义(如 `''这个''`)。反引号字符串默认不转义，正合适写 Windows 路径；另有 `\'` 开头的转义字符串，以及 `x0063` 这种前缀符 + 十六进制长度的字符串。
- **注释**：`#` 开头的整行注释。

## 和 JSON 双向互通

`@toJson` 和 `getJson` 都接受一个 `fd` 开关：`s.@toJson(fd: true)` 输出 FD，`s.getJson(fd: true)` 读入 FD。FD 的输出格式还有三档：`0` 是两个空格缩进、`1` 用 `>`、`2` 用 `n>`；`kvd` 控制键值之间的填充空白(默认 `32`，即空格)，`sse` 开关解压。`lib-json.fun` 把这些包成两组对称的入口——`JSON.Parse`/`JSON.Stringify` 与 `FD.Parse`/`FD.Stringify`。

FD 也不只用来写配置文件。解释器自己的宿主信息就是一段 FD，标准库里到处这样读：

```fun
var _hostFacts = 'host'.arg().getJson(fd: true);
```

`os`、`bits` 这些运行时事实，先用 FD 吐成字符串，再解析回结构。规范、文法、运行时元信息都落在同一种格式里，工具因此只需要懂一种东西。