📝 docs(tsl): restructure agent-facing reference
Rework TSL syntax, catalog, modules, and routing docs around deterministic agent lookup and generation. Split large catalog pages into focused function fact pages, remove obsolete pending/verified/unavailable paths, and update consistency tests for the new structure.
This commit is contained in:
+11
-12
@@ -1,13 +1,12 @@
|
||||
# TSL 命名规范(Naming)
|
||||
# TSL 命名偏好
|
||||
|
||||
文档类型:规范页
|
||||
文档类型:风格偏好页
|
||||
是否可直接用于生成代码:仅部分
|
||||
是否含已验证可执行示例:否
|
||||
是否含已验证反例:否
|
||||
遇到不确定时跳转到:[code_style.md](code_style.md)、[syntax/index.md](syntax/index.md)、[syntax/03_core_model.md](syntax/03_core_model.md)
|
||||
是否含可直接照写示例:否
|
||||
是否含不可照写反例:否
|
||||
遇到不确定时:[code_style.md](code_style.md)、[syntax/index.md](syntax/index.md)、[syntax/02_core_model.md](syntax/02_core_model.md)
|
||||
|
||||
本仓库命名规则与 Google C++ Style
|
||||
Guide 对齐:通过名字的“形状”快速判断实体类型(类型/函数/变量/常量等),减少阅读成本。
|
||||
本页记录本仓库/作者的命名偏好,不代表 TSL 语法事实。命名偏好与 Google C++ Style Guide 的实体形状思路对齐:通过名字的“形状”快速判断实体类型(类型/函数/变量/常量等),减少阅读成本。
|
||||
|
||||
以下出现的 `<...>` 形式只表示命名或注释模板占位,不是源码字面量。
|
||||
|
||||
@@ -51,7 +50,7 @@ Guide 对齐:通过名字的“形状”快速判断实体类型(类型/函
|
||||
## 3. 类型命名(Type Names)
|
||||
|
||||
AI 先按 `.tsl` 可执行脚本与 `.tsf` 模块/函数扩展判断文件模型。`.tsl` 里的语句区按顺序执行,函数/类声明区放在语句区之后;`.tsf` 用于可复用顶层声明并部署到解释器 `funcext`。本页只覆盖“需要命名的顶层实体”,不覆盖脚本语句本身;文件模型判断本身以
|
||||
`docs/tsl/syntax/03_core_model.md` 为准。
|
||||
`docs/tsl/syntax/02_core_model.md` 为准。
|
||||
|
||||
- **类与单元**使用
|
||||
`PascalCase`,不带下划线;名称应为名词/名词短语(通常单数),避免动词开头。
|
||||
@@ -69,13 +68,13 @@ AI 先按 `.tsl` 可执行脚本与 `.tsf` 模块/函数扩展判断文件模型
|
||||
TSL 的语法要求(仅 `.tsf`):每个 `.tsf`
|
||||
文件只能有一个顶层声明,且**文件基名必须与该顶层声明名字一致**。
|
||||
|
||||
- 更可靠的判断方式仍然是先看顶层内容,而不是只看扩展名;命名规范只是补充“命名后的实体如何取名”,不替代文件模型判断。
|
||||
- 更可靠的判断方式仍然是先看顶层内容,而不是只看扩展名;命名偏好只是补充“命名后的实体如何取名”,不替代文件模型判断。
|
||||
- 需要命名的顶层实体可以是 `function / procedure`、`type Name = class`、`unit`。
|
||||
- `.tsf` 代码文件:用于库/模块等“顶层声明”的首选承载文件;顶层声明可为
|
||||
`function / procedure`、`type Name = class`、`unit`,文件基名需与之同名。
|
||||
- `.tsl` 脚本文件:用于入口/编排层;允许直接写语句(如
|
||||
`a := 1; echo a;`),也可能出现顶层 `function / procedure` 骨架或 `program test;`
|
||||
这类验证样例外壳;如果同时出现脚本语句和函数/类声明,语句区在前,声明区在后;但风格上不把 `.tsl` 当成可复用顶层声明的默认落点,也不要求文件基名与函数名一致;可复用逻辑优先下沉到
|
||||
`a := 1; echo a;`),也可能出现顶层 `function / procedure` 骨架
|
||||
这类示例脚本外壳;如果同时出现脚本语句和函数/类声明,语句区在前,声明区在后;但风格上不把 `.tsl` 当成可复用顶层声明的默认落点,也不要求文件基名与函数名一致;可复用逻辑优先下沉到
|
||||
`.tsf`(见 `docs/tsl/code_style.md`)。
|
||||
- 注:`.tsf` 也是 TSL 源文件,命名/风格与 `.tsl` 遵循同一套规则。
|
||||
- **硬规则(仅
|
||||
@@ -85,7 +84,7 @@ TSL 的语法要求(仅 `.tsf`):每个 `.tsf`
|
||||
|
||||
- 基名统一使用 `PascalCase`,与顶层声明的推荐写法一致。
|
||||
- 示例:
|
||||
- `DailyEntry.tsl` 作为入口 / 编排脚本,主体是松散语句或验证样例外壳。
|
||||
- `DailyEntry.tsl` 作为入口 / 编排脚本,主体是松散语句或示例脚本外壳。
|
||||
- `UserAccount.tsf` 中定义 `type UserAccount = class ... end;`.
|
||||
- `DocxEnumerations.tsf` 中定义 `unit DocxEnumerations; ... end.`
|
||||
- `ParseConfig.tsf` 中定义 `function ParseConfig(...)`.
|
||||
|
||||
Reference in New Issue
Block a user