术语概要

　　本文档概述及约定 YSLib 基本的概念含义，主要用于开发。

　　一些术语概念适用各种不同的上下文，主要用于开发过程中的设计和规则说明。

　　术语以列表形式的条目列出。通过使用元语言语法 <相关范畴/上下文> 标记指示被修饰或被限定的概念的适用范围。不需要消歧义时，省略标记。

通用领域

　　除非另行指定，适用于任意上下文；但存在更具体的上下文的特定概念定义时，优先适用后者。

经验语义

　　经验语义解释的术语的含义总是假定可被实证，不需要进一步解释。

　　元语言中的标记使用经验语义。标记可被本文档中已归类的章节提供。

　　本文档中非形式地使用在特定理论中严格定义的、和本章的条目具有逻辑上相容的含义的概念时，不进一步解释。

自指

　　自指是概念定义形式上的自我指涉。

举例 “本章”是关于位置的自指。

　　有必要通过自指定义的概念，隐含引入定义内容的过程的循环论证。这些概念的精确内涵和外延依赖经验语义的实证，否则在自然语言语言中可能需要循环论证而失去定义的意义。此处的条目内容（包括链接的外部定义）仅仅供参考，而不是精确的内涵和外延。为简化复杂度，限制自指定义的概念都是名词。

举例 上述注释中，内涵和外延约定为以下非自指的概念，因此可依据本文档给出明确的定义来源。

举例 在程序语言理论中，上下文(context) 指形式上可继续补充内容的构造；文档可能非形式地使用和这个含义相容的概念。

  • 实体(entity) ：任意被自然语言表达的目标；不需要通过自然语言先验定义；参见经验语义。
  • 语义(semantics) ：参见经验语义。
  • 经验(experience) ：参见哲学或一般等价的经验语义。
  • 范畴(category) ：参见范畴论。
  • 态射(morphism) ：参见范畴论。
  • 归纳(induction) ：一种态射，可操作性参见经验语义。
  • 方法学(methodology) ：一个归纳经验得到的范畴；参见哲学或一般等价的经验语义。
  • 方法(method) ：方法学的一个子范畴；可操作性参见经验语义。
  • 概念(concept) ：参见逻辑学。
  • 上下文(context) ：一种概念范畴适用的态射；参见经验语义。

非自指

　　包含多个一般领域的概念。

  • <名词> 形式(form) ：参见经验语义和数学。
  • <概念> 内涵：参见逻辑学。
  • <概念> 外延：参见逻辑学。
  • <概念> 定义(definition) ：确定概念内涵和外延的方法；参见任意一种形式逻辑学。
  • <动词> 抽象(abstracting) ：通过经验语义定义概念范畴或集合的方法。
  • <名词> 抽象(abstraction) ：<动词> 抽象的结果。
  • <动词> 封装(encapsulating) ：从某一个范畴中抽象一个子范畴的方法。
  • <名词> 封装(encapsulation) ：<动词> 封装的结果。
  • 规范(specialization) ：一种提供在特定上下文中可定义的描述的封装，参见工程学（特别是软件工程学，下同）。
  • 接口(interface) ：一种封装，参见工程学。
  • 实现(implementation) ：一种封装，参见工程学。
  • 重用(reusing) ：参见经验语义和工程学。
  • 不变性(invariance) ：满足某种等价关系（自反、传递、对称的二元关系）。
  • 不变量(invariant) ：具有不变性的实体。参见数学和契约式程序设计。
  • 状态(state) ：可以和其它实体关联的、可在某个上下文中保持变化或不变的实体。同一状态总是保持变化或保持不变。状态变化的含义参见经验语义、数学或另行指定。
    • 可变状态(mutable state) ：在某个上下文中可能映射到若干其它状态的状态。
    • 不可变状态(immutable state) ：不是可变状态的状态。
  • <动词> 派生(deriving) ：基于重用的操作。
  • <名词> 派生(derivation) ：<动词> 派生的结果。

计算机科学

　　包含多个关于数学、逻辑学和计算机领域的概念。

  • <动词> 形式化(formalize) ：建立数学意义上的严格形式。
  • <名词> 形式化(formalization) ：建立形式的过程。
  • 形式方法(formal method) ：包含形式化的方法。
  • <动词> 建模(model) ：建立形式化输出的形式。
  • <名词> 模型(model) ：建模的结果。
  • 可计算性(computability) ：参见数学。
  • 计算(computation) ：由可计算性定义的操作的等价类。
  • 计算模型(computation model) ：描述计算的模型，是对计算建模的结果。
  • 集合(set) ：一种数学模型，参见 NBG 集合论。
  • 类(class) ：参见 NBG 集合论和范畴论。
  • 真类(proper class) ：参见 NBG 集合论和范畴论。
  • 二元关系(binary relationship) ：一种基于集合上定义的数学实体。
  • 等价关系(equivalence relationship) ：自反的(reflexive) 、对称的(symentric) 和传递的(transitive) 的二元关系。
  • 等价类(equivalence class) ：等价关系划分集合得到的类。
  • 序列(sequence) ：有序集合。
  • 形式语义(formal semantics) ：使用形式化的方式表达的语义。
  • 形式语言(formal language) : 特定形式化的方式确定的元素的全集。
    • 注释 这也可能作为语言规则对应的某种形式语义。这同时是语言对应的语法的外延。
  • 计算复杂度(computational complexity) ：某个形式化计算模型中以有限的正整数作为模型决定的规模(metric) 作为参数的渐进(asymptotic) 性质确定的度量。
    • 时间复杂度(time complexity) ：描述步骤规模的计算复杂度。
    • 空间复杂度(space comlexity) ：描述存储规模的计算复杂度。

规范

　　包含提供规范的实体定义。

  • 符合性(conformance) ：满足规范的实现性质。
  • 要求(requirement) ：规范对实现的作为判断符合性的条件。
  • 约束(constraint) ：可被形式表达，用于限制和明确行为的规则。不一定使用形式表达。
  • 违反(violation) ：对约束指定的条件的不满足。
  • 过时的(obsolesent) ：已确认因为存在更合适的选项而建议不继续使用的（接口/特性）。
  • 废弃的(deprecated) ：过时的但因为兼容性等原因，暂时保留的、一般可提供替代的接口或特性。
  • 语言：模型或者非形式地其它方式定义的一种接口。
  • <语言> 接口(<language> interface) ：和表达语义有关的语言的可见的特征。

　　包含关于语言的规范的定义。

  • <语言> 实现(<language> implementation)：对语言规则中的要求的<非自指> 实现。
  • <语言> 人类接口(human interface) ：语义仅对人类有意义（内容改变时可以导致语义的差异性），不提供为涉及作为计算模型实现的语言接口。
  • <语言> 机器接口(machine interface) ：对机器（或特定语言实现的特定部分）有意义的语言接口。注意不同语言实现组成部分可以不同。
    • 举例 对 C 语言的预处理器，C 源代码中的空白符是机器接口，而对翻译器来说则不是。就源代码而言，机器接口总是人类接口的子集。
  • <语言> 特性(*<language> feature) ：作为功能提供的人类接口。
  • 语言规则(language rule) ：约定可实现及应被实现的语言接口的描述，可包含语言特性的表达。
  • 语言规范(language specialization) ：包含正式的(normative) 的语言规则的集合的规范；或称语言规格说明。
  • 语言实现(language implementation) ：语言提供的接口的实现，是语言的表现形式，可以是具体语言实现或抽象语言实现之一。
    • 具体语言实现(concreate language implementation) ：能最终完全表达为可预测的物理现象一一对应的表达可计算性的实现（如机器指令），一般应为程序。
    • 抽象语言实现(abstract language implementation) ：非具体语言实现的语言实现。形式意义的标准定义的语言属于此类。
  • 派生语言实现(derived language implementation) ：派生已有实现的部分或全部得到的语言实现。以下简作“派生实现”。
  • <语言> 实现环境(environment of implementation) ：对应特定语言实现的特定不变状态（对机器来说可以是配置项，对人来说不确定，所以一般忽略）的集合。
  • <语言> 互操作(interoperation) ：不同的语言实现环境中发生的交互。
  • 未定义的(undefined) ：可能导致违反规范的约束但语言规范同时没有要求提供任何可能影响符合性的保证（如具有诊断消息）的。
    • 注释 表示置于语言规则下的行为等不可预测。
  • 良定义的(well-defined) ：明确地非未定义的。
  • 未指定的(unspecified) ：规范隐式或显式地允许但不要求唯一确定的至少一个实现选项。
    • 注释 通常允许多种不同的选项；但在特定实现配置下，规则中未指定的选项也可被限制为只有一种可行的选项。
    • 注释 同一个实现或者不同实现可能确定地或非确定地选取不同的选项而不保证表现一致。
  • 由实现定义的(implementation-defined) ：取决于各个具体语言实现的，要求有文档说明。
  • 由派生实现定义的(derived-implementation-defined) ：取决于各个派生语言实现的，要求除存在默认定义或被派生实现的部分有明确的文档说明。

程序设计语言

　　提供上下文 <程序设计语言> ，特别是语言规范的定义。

　　主要用例参见版本库中的项目文档 doc/NPL.txt 。

  • 广义实体：<通用领域> 实体。语言抽象的目标，不另行定义（意义最终取决于自然语言）。
  • 名称(name) ：一种特殊的广义实体，专用于指称另一个广义实体。
  • 实体(entity) ：非名称的广义实体。
  • 表示(representation) ：以一个符合某种形式的约束的实体指称另一个实体。
  • 符号(symbol) ：语言规则允许的不使用其它对象表示的对象。符号可实现名称。
  • 字母表(alphabet) ：符号在语言中的全集。
  • 串(string) ：可能重复出现的符号的有限序列。
  • 文法(grammar) ：描述任意的可形式化的语言规则。
  • 语法(syntax) ：以语言中的串作为基本元素，描述语言的字面(literal) 结构模式(pattern) 的语言规则，通常是文法的一部分。
  • 语义(semantics) ：非语法的考虑逻辑上的释义(interpretation) 或含义(meaning) 的规则、原理和过程，通常可被语法以外的文法描述并可约束含义的表达。
  • 实例(instance) ：具有代表性含义的集合的元素。
  • 代码(code)：任意有限的语言的实例片段组成的语法范畴。
  • 伪代码(pseudo code)：抽象语言实现的语言的代码。
    • 注释 习惯上和具体语言实现代码完全一致的代码可以不作为伪代码考虑。
  • 程序(program) ：具体语言实现接受的以代码表示的输入，或被变换后对应的输出。
  • 行为(behavior) ：语言实现或在满足符合性的具体语言实现中的程序的外部表现。基于可操作性考虑，一般仅约束实现的机器接口。
  • 计算作用(computational effect) ：可被某个形式化计算模型描述的行为。
  • 作用(effect) ：语言支持的一定上下文内的表达式规约的结果的计算作用，包括计算得到的值、产生的副作用以及其它可由区域和变化的状态二元组描述的实体。
  • 翻译(translation) ：不同语言的程序之间的变换，可作为语言实现的形式。
    • 注释 输入和输出具有相同表示的恒等变换不被视为翻译。
  • 运行(run) ：实现程序或组成程序的实体的行为的动作。
  • 加载(load) ：运行程序或组成程序的实体时从实现环境取得相关实体的动作，可蕴含创建这些实体的副本或翻译其中的代码到特定形式。
  • 执行(execute) ：处理程序或组成程序的实体，使这些实体或实体的副本作为资源被消费而蕴含这些实体被运行，同时可能蕴含消费实现环境的其它资源。
    • 注释 执行强调资源的消费，是运行的子集。资源被消费后不再可用。因此，除非同时蕴含资源的再生(reclaim) ，被执行的同一实体不预期被再次执行。再生资源包括实体加载时翻译或取得副本，及实现环境中补充的替代资源。
  • 解释(interpretation) ：通过不依赖显式指定的附加的程序翻译而直接运行表现行为的具体语言实现的形式。
  • 源语言(source language) ：翻译的输入的语言。
  • 目标语言(destination language) ：翻译的输入的语言。
  • 源代码(source code) ：源语言编码的代码。
  • 源程序(source program) ：形式为作为翻译的输入的源代码程序。
  • 复杂度(complexity) ：以程序的规模作为参数的关于程序的直接执行的计算复杂度。
  • 元语言(metalanguage) ：描述其它语言的语言。
  • 对象语言(object language)：被元语言操作或实现的语言。
  • 元编程(metaprograming) ：使用元语言编程。
  • 反射(reflection) ：元语言和对象语言相同的元编程。
  • 具现(reification) ：在对象语言中以数据模型作为关联实体以表示程序的语义。
  • 诊断(diagnostics) ：明确的对特定预期或非预期执行的行为的响应的总和。
  • 诊断消息(diagnostic message) ：用于和用户交互的表现诊断的告知及提示。
  • 未定义行为(undefined behavior) ：未定义的行为。
  • 良定义行为(well-defined behavior) ：良定义的行为。
  • 未指定行为(unspecified behavior) ：未指定的行为。
    • 注释 由实现选取语言规范中可能允许的指定行为的不确定选项，这些选项可能由显式或隐式的语言规则确定。
    • 注释 推论：由实现定义的行为是未指定行为。在本文档中，为最小化依赖，不在正式规则中明确这些关系。
  • 语言特性(language feature) ：语言提供的功能接口，可以是具体语言特性或抽象语言特性之一。
  • 具体语言特性(concrete language feature) ：完全没有派生语言实现定义的语言特性。
  • 抽象语言特性(abstract language feature) ：非具体语言特性的语言特性。
  • 外部环境(external environment) ：和程序及被翻译的程序没有交集的和实现环境无关的状态。
  • 外部表示(external representation) ：具有特定形式的用于和外部环境交互的表示。
  • 内部表示(internal representation) ：非外部表示的表示。

项目管理

　　提供上下文 <项目> 。

　　主要用例参见版本库中的项目文档 doc/ProjectRules.txt 。

  • 涉众(skateholder) ：项目关联的各方的主体。
  • 角色(role) ：依据项目过程中起到的作用，对项目涉众实行一些附加归类。
    • 注释 项目的角色同时可用于项目阶段的描述中。
  • 用户(user) ：使用项目输出的项目涉众。
  • 维护者(maintainer) ：决定项目中各个部分的内容的用户。
    • 注释 维护者可参与和维护部分相关的项目决策。
  • 开发者(developer) ：参与程序库和开发工具的功能修改的用户。
    • 注释 开发者可参与公开的构建过程以完成这些修改。
  • 最终用户(end user) ：独立为项目过程的用户。
    • 注释 最终用户可以不参与提前(ahead-of-time) 构建的项目过程。基于认知需求的差异可能需要从一般用户中单独区分。

依赖管理

　　项目管理的客体被分解为特定关联的依赖项。任意两个依赖项之间存在反对称和传递的二元关系称为依赖关系。严格依赖关系是反自反的依赖关系。

　　依赖项和依赖项之间的严格依赖关系统称为依赖(dependency) 。

依赖引用

　　因为依赖关系的传递性，多个依赖关系可能存在无法满足严格依赖关系的情形，即循环依赖(cyclic dependency) 。这导致以确定的顺序解析依赖不可行，增加维护成本。

　　为了避免一定层次上的循环依赖，以该层次内组件为顶点的依赖关系的关系图应明确组织为有向无环图。 在最简单情况下依赖关系可退化为线性顺序依赖。

内部依赖和外部依赖

　　项目中的组成部分之间的依赖称为内部依赖，其它依赖为外部依赖。

源代码

　　源代码用于生成指定目标代码(target code) 。

　　通常源代码以文件形式保存，即源代码文件(source code file) ，简称源文件(source file) 。

版本库

　　项目使用的版本控制系统(version controlling system) 具有版本库(repository)作为持久存储实体。

　　当前使用的主要版本控制系统为 Mercurial 。因为是分布式版本控制，也用于直接分发源代码。

　　每个文件系统上存储的版本库实例中， .hg 目录存储版本库元数据。

设计和模型

环境

　　程序中的某一部分的外界称为环境(environment)。根据限定程序的范围，可以有更确切的定义，如实现环境（对一类语言实现而言）、运行时环境（对共享实现环境的一类程序而言）。

　　一般地，实现环境可以分为独立环境(freestanding environment) 和宿主环境(hosted environment) ，区分依据为是否依赖宿主（对部署在单一计算机上的实现，一般指操作系统）的支持。因此，环境有时指操作系统及其提供的外部服务的集合。

　　一些语言，如 ISO C 和 ISO C++ ，可以同时支持宿主环境和独立环境的实现，对应独立实现(freestanding impementation) 和宿主实现(hosted impementation) 。

平台

　　环境中决定程序适用环境的被依赖的特定资源集合称为平台环境(platform environment)，简称平台(platform)。平台的典型例子有：

　　平台的内涵是资源的集合，其构成并非任意。构成平台的特定准则应使之保持相对的稳定和可预期，即可配置；即平台是名义的(nominal) 可配置的资源集合。

　　若平台包含的资源是已知的，则不需要平台的观念，分析其资源子集（即便不构成平台）即可解决几乎平台抽象涉及的所有技术问题（同时这也是定义一个具体平台的基础）。但在简化资源集合的全局性质分析（如比较资源配置方案）和名义抽象以隐藏实现（如为开发者提供预设环境集合）的应用角度上，平台仍有被单独讨论的意义。

兼容性和可移植性

　　若一个依赖项对应的平台可以替换，则此依赖项和此平台兼容(compatible) 。兼容性(compatibility) 是平台兼容的二元关系。兼容性不是一种等价关系，因为不保证传递。

　　替换平台的过程称为移植(porting) 。移植的可行性称为可移植性(portability) 。

　　兼容任意平台的依赖项被称为是平台中立(platform-neutral) 的。

　　当平台中立的依赖项的依赖能被自动满足而不需要考虑时，是平台无关(platform-independent) 的。平台中立实质蕴含平台无关。

依赖和外延

　　若平台之间不出现平台的实现（如开发语言的实现）和环境自身的相互依赖，则这些平台相互独立(independent) 。总是保持相互独立的一组平台称为独立平台(independent platforms) 。每一组独立平台保证可以相对于其它独立平台分离开发和测试。

　　注意以上术语和 ISO C 和 ISO C++ 定义的宿主实现(hosted implementation) 和独立实现(freestanding implementation) 的关联和区别。

　　典型的应用场景约定以下类型的平台：

  • 构建平台(build platform) ：运行开发环境的平台。
  • 宿主平台(host platform) ：运行构建平台输出代码的平台。
  • 目标平台(target platform) ：运行最终目标代码的平台。

　　若宿主平台和构建平台一致，称为本机构建(native build) ；否则，称为交叉构建(corss build) 。

　　通常构建工具在本机构建时提供对构建平台的检查以确定自身是否能够运行；交叉构建环境需要显式指定。

　　目标平台通常和宿主平台一致。指定目标平台的理由是，存在最终不一定在宿主平台上运行的程序，其运行的环境可能需要宿主平台不保证支持的特性，这典型地包括：

  • 构建的程序自身是生成其它程序的程序，如编译器和链接器。这些程序生成的平台是目标平台，不需要和它们的宿主平台相同。
  • 构建的程序可以在宿主平台上运行，但在其它平台上具有更完全的特性集。后者被作为目标平台。

注意 此处的宿主平台具有相对意义，不一定脱离被运行的目标平台。一个宿主平台通常自身是宿主实现平台，但这点不被保证。

模拟和仿真

　　模拟(emulation) 指适配和运行为不同平台设计的程序，广义上包括以下两类：

  • 环境模拟(environment emulation) ：使用模拟器(emulator)或虚拟机(virtual machine) 等作为宿主平台的程序，模拟运行环境的通用解决方案。
  • 程序模拟(program emulation) ：直接以运行时环境适配层嵌入宿主平台运行时，在具体程序中提供类似被模拟的目标平台的具体特性和接口。

　　运行模拟程序的环境和被模拟环境分别是宿主平台和目标平台。

　　注意虚拟机在这个意义下是广义的模拟器，但一般仍然分别对待。

　　环境模拟和程序模拟的主要差异为是否独立的、专用的宿主平台程序作为中介以维护目标平台和宿主平台的隔离。

　　在一般意义上，仿真(simulation) 指对需要分析的问题建立的模型(model) 的过程、方法和机制，在软件工程以外也被称为模拟，如计算机模拟(computer simulation) 。对于以计算机系统为目标的仿真，建立的模型可以是具体的实物（包括硬件和软件），称为仿真器(simulator) 。以软件接口为主要操作方式实现的仿真器同时实现了环境模拟，但侧重不同：精确重现需要分析行为，而非实用的功能等价性和体系中的可替换性。

平台配置

　　实际的平台实现可能复用部分实现，配置之间可存在某种构成依赖关系的偏序关系（如继承关系）。这些在项目中所有被配置的平台称为公共平台(common platform) ，其中能对应生成输出的称为具体平台(concrete platform) ，否则为抽象平台(abstract platform) 。

标识

　　不同平台可以标识符加以区分。由于平台受到不同环境因素决定的正交性，通常此类标识符可以分解为表示这些正交环境的标识符的元组形式，用 - 等字符分隔。

　　一种常用的方式是 GNU 构建系统的系统类型(en-US)，经典表示方式为三元组(triplet) ，或其省略形式：

  • 一般包括体系结构、系统厂商和系统软件环境
  • 第一项不可省略，之后的项可省略
  • 体系结构一般指定 CPU 要求的最小指令集架构
  • 系统厂商指集成平台的环境厂商
  • 系统软件环境保证满足 ABI 要求，可以包含操作系统及本机语言运行时实现的名称

　　确定为宿主环境时，系统软件同时指定操作系统和运行时环境而拆分为两项，三元组扩充为四元组，如 Gentoo 使用的 CHOST (en-US)。

　　在不够充分体现平台的必要差异（尤其是体系结构相关的配置）时也可通过自行定义标识符并指定与三元组的对应关系，如 Debian multiarch (en-US) 。

　　除非必要时另行指定， YSLib 使用三元组作为指定平台标识的基本形式。

多平台构建

　　构建系统中可能涉及多个平台。

　　运行构建系统的环境和被构建的程序的环境不需要相同，对应的平台分别称为宿主平台(host platform) 和目标平台(target platform) 。宿主平台和目标平台相同时称为本机(native) 构建；不同时称为交叉(build) 构建。

　　多个构建过程可能串联组成更大的构建过程。不同构建过程存在输出和输入之间的依赖。此时，前一过程输出的目标平台需要兼容于后一过程作为输入的宿主平台，否则无法直接运行。典型情况下这些平台是相同的，但也可以存在平台之间自身保证二进制互操作兼容性（如支持 x86_64 的体系结构上混用 i686 和 x86_64 ）的情况。

　　一些构建系统如 GNU 工具链(en-US) 使用更复杂的术语，单独引入构建(build) 平台。为确保一般性并简化模型， YSLib 不使用这个概念，而把构建平台作为第一级构建过程（即 GNU autoconf 的“配置”）的宿主平台。