🧬 E 语言设计

双层结构 · 动态算子空间 · AI 原生语法规范 —— 设计理念总纲（2026-09-06 定稿）

加载中…

一、双层结构（核心设计理念）

E 从第一天起就是两层语言：语义层描述"状态如何演化"，结构层描述"逻辑如何执行"。两层各有独立的语法、编译路径与验收方式：

┌─────────────────────────────────────────────────────┐
│  语义层 (Semantic Layer) —— 声明式 / 开放算子空间      │
│  Ω = space<256>("Analytics")                         │
│  A = Ω | create("初始化")                            │
│  B = A | update("用户登录") | read()                 │
│  验收：签名/fitness 评分（软验收）                     │
├─────────────────────────────────────────────────────┤
│  结构层 (Structural Layer) —— 命令式 / 封闭语法集      │
│  space<8> std { fn gcd(a: u64, b: u64) -> u64 }      │
│  x | std::gcd(y) | assert_eq(21)                     │
│  验收：GCC 编译 + 断言三重门（硬验收）                 │
├─────────────────────────────────────────────────────┤
│  @augment 逃生舱 —— 两层的交界（E 独创）               │
│  函数体由 LLM 填充，签名与断言由 E 管死                │
│  → LLM 写实现，机器验契约；E 表达不了的算法永不堵死     │
└─────────────────────────────────────────────────────┘

为什么这样切：LLM 擅长意图与模式（语义层给它自由），不擅长精确边界与状态追踪（结构层用封闭语法+断言把它圈住）。同范本：SQL 的声明查询 vs 存储过程、K8s 的期望态 YAML vs Go 运行时。E 的独特点：把"LLM 填语义、机器验结构"做成了编译器内建的分界线。

二、原生解析管线（elangc_native）

结构层编译器已是纯 C 单文件实现（21KB，零 Python）：

.e 源码
  ↓ 词法分析 (C 实现，行号锚定)          ← 确定性，零 LLM
  ↓ 递归下降解析 → 骨架 AST              ← 确定性，零 LLM
  ↓ C 发射器 (space→声明区, ns::fn→ns__fn, 管道→函数调用)
  ↓ @augment 空函数体 → LLM 填充          ← LLM 唯一入口
  ↓ fork-exec GCC -O2 + ASan 沙盒
  ↓ 三轮运行 + 断言验收 (assert_eq)
可执行文件 ✅

验收成本实测：编译 0.4s / 内存 3MB / 运行 9ms——瓶颈 95%+ 在 LLM 侧。

三、动态算子空间（历史与去向）

Ψ_agent = Ω_agent | project("Analyze Task") | optimize() | resolve();

四、语法集：现状 → 目标（v2）

现状（已实现，elangc_native 实测）

space<N>fnletif / elsewhileforreturn管道 x|f(y)assert_equ8~u64 · i8~i64 全定宽(1.6.5+含i16/i32)

⚠️ 2026-09-24 口径修正②：for 两形态（C式三段/E式 for-in）当前二进制均报语法错误，golden v2_0916_for.e 未过（22/27），标签降为「设计稿」，与 map/filter/reduce 同档——落地时 golden 自动验收。 / 2026-09-15 口径修正：@augment 为设计目标（语法层暂无解析支持，勿当作已实装）；bool 字面量 true/false 暂不可用（TYPE_ERROR），bool 只能由比较式产生；while(1) 可编译但"上限可判定"属 Linter 约定非编译期强制。

目标（v2 待补，按 AI 亲和度排序）

控制流设计哲学：while/for 是给"精确状态循环"的逃生舱（保留但降级）；主推组合子（声明"做什么"而非"怎么转"）——实测 LLM 在 for 循环边界（off-by-one）上失误率显著高于组合子。

诚实口径：语法集没有最先做完，是走了"管线先行、语法随任务生长"的路线（详见反思）。v2 起转为规范先行：语法集文档定稿 → 一致性测试集入池 → 编译器实现。

五、AI 原生语言的七个部件

五·五、能力边界四档总表（2026-09-15 实测定版）

六、五条边界（语言成立红线）

1. 确定性核心零 LLM —— 词法/解析/类型/验收，LLM 不得进入
2. LLM 只准出现在两处 —— 生成实现、修复报错，且输入输出都过验收门
3. 语法集封闭+版本化 —— 扩展只能过池验收进编译器（新算子走注册协议）
4. 每个构造必须有 canonical form + 机器验证器
5. 逃生舱永存 —— @augment/FFI 在，语言永不堵死

六·五、Non-Goals（明确不做，与"没做完"严格区分）

七、待讨论：激进设计候选（未证明，不采纳）

八、设计理念一句话

相关：语言手册 · 语义算子 API · 加入蜂网 · 蜂网账本