169 lines
8.8 KiB
Markdown
169 lines
8.8 KiB
Markdown
# 11 · 模块与程序执行
|
||
|
||
0/22 项已确认。当前推进 11-01；本分类尚未完成选择。
|
||
|
||
本页整理原讨论的问题、验收要求和候选方案。勾选代表讨论中已确认的规则，不代表编译器或运行时已经实现。
|
||
|
||
## 11-01 模块的职责与顶层内容
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确模块主要承载声明、可执行初始化，还是可实例化的定义；说明导入与执行的关系。
|
||
|
||
## 11-02 模块的组织单位
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确模块与文件、目录、包的对应关系，以及嵌套模块、多文件模块是否支持；说明不合法的组织形式。
|
||
|
||
## 11-03 模块身份
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确判断“同一个模块”的依据；覆盖路径别名、重复引用及不同版本，说明身份冲突如何处理。
|
||
|
||
## 11-04 名称与路径解析
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确绝对引用、相对引用、搜索位置及优先级；说明找不到目标、存在多个候选时的行为。
|
||
|
||
## 11-05 依赖与版本选择
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确依赖由谁声明、版本由谁选择，能否同时使用多个版本；划清语言、构建工具和包管理器的职责。
|
||
|
||
## 11-06 导出与可见性
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确默认公开范围、显式导出及内部成员的访问规则；说明越权引用如何失败。依赖【名称与作用域】。
|
||
|
||
## 11-07 导入形式与名称冲突
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确整体导入、成员导入、别名、重新导出和批量导入的支持范围；说明重名与遮蔽规则。
|
||
|
||
## 11-08 跨模块绑定语义
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确导入获得值、持续关联的绑定，还是其他形式；说明重新赋值和修改共享对象的区别。依赖【名称与作用域】【对象与类型模型】。
|
||
|
||
## 11-09 依赖检查与条件导入
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确依赖必须何时可用，是否支持可选或条件导入；说明未使用但缺失的依赖是否导致失败。依赖【编译与执行方式】。
|
||
|
||
## 11-10 初始化触发与次数
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确初始化何时发生、何种范围内执行几次，以及重复导入的行为。
|
||
|
||
## 11-11 初始化顺序与并发
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确依赖之间的初始化顺序，是否允许并发或异步初始化；说明顺序不确定时有哪些保证。依赖【并发与异步】。
|
||
|
||
## 11-12 循环依赖
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确允许哪些循环，何时检测；说明访问尚未准备好的定义或状态如何处理。
|
||
|
||
## 11-13 初始化失败
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确失败后模块处于什么状态，能否重试，如何处理已发生的副作用，以及依赖方会得到什么结果。依赖【错误处理】。
|
||
|
||
## 11-14 模块状态与隔离
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确是否允许可变模块状态、由谁持有、何时结束，以及多个程序环境能否相互隔离。依赖【内存与资源管理】。
|
||
|
||
## 11-15 程序入口的确定
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确入口是指定函数、指定模块、顶层代码还是其他形式；说明缺失或存在多个入口时如何处理。
|
||
|
||
## 11-16 入口的输入输出契约
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确参数如何传入、入口允许返回什么，以及如何形成退出结果；说明不合法的入口签名。依赖【类型系统】【标准库与宿主接口】。
|
||
|
||
## 11-17 启动流程
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确依赖准备、模块初始化与入口执行的先后关系；说明启动中途失败时入口和清理是否执行。
|
||
|
||
## 11-18 动态装载与模块生命周期
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确是否支持运行中加载、重新加载和卸载；如支持，说明旧引用、状态与资源的去向；如不支持，记录限制。
|
||
|
||
## 11-19 正常结束
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确入口返回、显式退出与后台工作之间的关系；说明哪些条件代表程序真正结束。依赖【并发与异步】。
|
||
|
||
## 11-20 异常与外部终止
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确未处理错误、取消、外部终止请求和强制终止分别有什么保证；说明错误报告与退出结果。依赖【错误处理】【并发与异步】【宿主接口】。
|
||
|
||
## 11-21 清理协议与顺序
|
||
|
||
- [ ] 待讨论
|
||
|
||
明确清理动作如何注册或归属、执行顺序、能否异步，以及清理自身失败或重复触发的处理。依赖【内存与资源管理】【错误处理】。
|
||
|
||
## 11-22 跨分类一致性验收
|
||
|
||
- [ ] 待讨论
|
||
|
||
用普通启动、共享依赖、循环依赖、初始化失败和退出清理等完整场景检查规则；相关分类决定已对齐，且没有未解决的阻塞，才可完成。
|
||
|
||
## 当前问题的方案与语言对照
|
||
|
||
以下沿用原讨论材料；建议和参考语言的做法均不自动成为本语言规则。
|
||
|
||
当前仍是 **11-01：模块的职责与顶层内容**。要决定的是：模块顶层能否执行读取配置、打开连接等动作，以及这些动作是否由导入自动触发。
|
||
|
||
相关语言的对照如下。下述好处与代价是设计取舍分析，不是在断言它们的历史设计动机。
|
||
|
||
| 语言 | 规则与具体行为 | 取舍及对我们的启发 |
|
||
|---|---|---|
|
||
| **Python** | 对普通源码模块，常规首次导入会执行模块代码。例如顶层 `current = read_config()` 会在导入时调用函数；后续命中模块缓存时通常不再执行。这里说的是 Python 导入规则，并非 CPython 独有的优化。[官方参考](https://docs.python.org/3/reference/import.html#loading) | 顶层写法直接，容易提供共享状态；但一次导入可能读文件、修改环境或抛出异常。对应我们的 **B**。 |
|
||
| **JS：ES Modules** | 模块允许顶层语句。例如模块中写 `console.log("loaded")`，该模块被求值时就会打印；普通静态导入会使依赖参与求值。导入声明的连接过程与模块代码求值是不同阶段。这里专指 ESM，CommonJS 另有规则。[ECMAScript 规范](https://tc39.es/ecma262/multipage/ecmascript-language-scripts-and-modules.html#sec-modules) | 能自动执行依赖的准备动作；也需要处理副作用、初始化顺序和失败。提醒我们区分“找到并连接定义”和“执行初始化”。 |
|
||
| **TS** | 运行时模块行为由实际采用的 JS 模块格式和宿主决定，TS 不提供独立运行时。`import type { Config } ...` 会从输出 JS 中消除，因此这条导入本身不会触发运行时加载。[官方文档](https://www.typescriptlang.org/docs/handbook/modules/reference#type-only-imports-and-exports) | 类型依赖可以与运行时依赖分开，但要明确两者的区别。启发是：需要一个类型，不一定需要运行其所属模块；是否采用该机制留给后续任务。 |
|
||
| **Go** | 包顶层不能任意写执行语句，但变量初始化可以调用函数，如 `var current = readConfig()`；还可以写自动执行的 `func init()`。程序启动时先初始化依赖包，再运行入口。[语言规范](https://go.dev/ref/spec#Package_initialization) | 顶层结构规整，仍可自动准备共享状态；副作用仍可能藏在变量初始化里。说明**“顶层只准声明”并不等于“没有自动执行”**。 |
|
||
| **Rust** | 模块是定义项的容器，没有普通的“导入即执行模块体”机制。直接在模块体中写 `read_config();` 不合法；普通 `static` 的初始化表达式要求能在编译期求值，不能直接读取运行时配置文件。可把读取动作放入函数，由调用者调用。[模块规则](https://doc.rust-lang.org/reference/items/modules.html)、[静态项规则](https://doc.rust-lang.org/reference/items/static-items.html) | 普通模块使用不会自动读取配置，启动动作更明确；调用者需要组织初始化。对应我们的 **A** 方向。 |
|
||
|
||
还有一点需要澄清：**A、B 两种模块都可以导出 `create(config)` 这样的普通函数，用它创建多个独立状态。** 只有当我们希望语言本身支持“创建模块实例、给实例连接依赖”时，才需要之前的 **C**；普通对象或函数已经能解决不少隔离需求。
|
||
|
||
因此当前三个选择保持不变：
|
||
|
||
- **A．显式调用**：模块提供定义；读取配置等运行时动作放入函数，由调用者启动。还需明确允许哪些顶层初始化表达式，才能保证声明中不会暗藏这些动作。
|
||
- **B．自动初始化**：模块可以带运行时初始化，使用模块时由系统安排执行；触发时机、次数和失败处理分别在后续任务决定。
|
||
- **C．显式模块实例**：导入定义后，由调用者创建带状态的模块实例；语言需要提供实例创建和依赖连接规则。
|
||
|
||
**我暂建议 A**：它让初始化失败发生在明确的调用处，也方便调用者决定状态如何共享。代价是程序需要多写一些启动与状态传递代码。如果你希望模块直接提供“准备好的共享服务”，B 会更顺手。这个建议尚未成为决定。
|
||
|
||
## 讨论来源
|
||
|
||
《语言设计 11：模块与程序执行》，整理日期 2026-10-28。章节编号沿用原清单。
|
||
|