﻿/*
	© 2012-2014 FrankHB.

	This file is part of the YSLib project, and may only be used,
	modified, and distributed under the terms of the YSLib project
	license, LICENSE.TXT.  By continuing to use, modify, or distribute
	this file you indicate that you have read the license and
	understand and accept it fully.
*/

/*!	\file NPL.txt
\ingroup Documentation
\brief NPL 规格说明。
\version r589
\author FrankHB <frankhb1989@gmail.com>
\since build 304
\par 创建时间:
	2012-04-25 10:34:20 +0800
\par 修改时间:
	2014-05-01 01:18 +0800
\par 文本编码:
	UTF-8
\par 模块名称:
	Documentation::NPL
*/


/*

@0 体例和适用范围：
引用标记参见 [Documentation::CommonRules @@0.1] 。
项目范围参见 [Documentation::ProjectRules @@1.1] 。
本文档适用于 NPL 及实现(@2.1.2) 。
编码细节和其它规范参见 [Documentation::Designation] 。

@1.1 设计的基本原理、表达形式和抽象：
设计的出发点：构建一个可用计算机实现的语言。
原始目的：在以标准 C++ 环境（宿主实现）的程序框架中嵌入配置和脚本操作。
扩展目的：渐进地向独立的计算机软件系统演进，探究能适用于各个领域并以计算机实现的通用语言。
本文描述基于此出发点的 NPL(Name Protocoling Language) 及其参考实现。

@1.2 理论背景、工具和依据：
基本内容参见 [Documentation::CommonRules @@2.1] 。

@1.2.1 组织概念模型：
略。

@1.2.3 设计意义：
参见 [Documentation::Designation @@1.2.3] 。

@1.3 构建原则：
基本内容参见 [Documentation::CommonRules @@2.2] 。
其它参见 [Documentation::Designation @@1.3] 。

@1.4 领域设计原则：

@1.4.1 原则性描述：
关于设计和实现的哲学。

@1.4.1.1 本体论：
语义的存在体现本质。

@1.4.1.2 价值观：

@1.4.1.2.1 变化的自由：
在明确需求的前提下，尽可能保证对现状按需进行改变的可行性和便利性。
适用于一般需求。
对于计算机软件：尽量避免不必要地损失可修改性，便于保障按需引入或除去接口(@2.1.2) 及其实现的自由。
在满足需求的前提下，修改应尽可能少地有碍于其它的接口。

@1.4.1.2.2 避免不必要付出代价：
尽可能减少影响需求实现的成本。
适用于一般需求。
对于计算机软件：不为不需要的特性付出代价（现代 C++ 的 no overhead 原则）。

@1.4.1.2.3 最小接口原则：
在确定的范围内尽可能少地提供必须的接口，以避免影响接口适应需求的能力，同时减少复杂性。
适用于一般设计。
对于需要在计算机上实现的人工语言设计：设计语言不应该进行功能的堆砌，而应该尽可能减少弱点和限制，使剩下的功能显得必要（参照 Scheme ）。

@1.4.1.3 形而上学：

@1.4.1.3.1
语言设计独立于语言实现(@2.2) 。
适用于计算机语言设计。

@1.4.1.3.2
语言实现包括库设计。
适用于可复用实现的计算机语言设计。

@1.4.1.4 方法论：

@1.4.1.4.1 避免不成熟的优化：
参照 D.E.Knuth ： “ Premature optimization is the root of all evil. ”。
适用于一般需求。
适时收缩理论长度以照顾可操作性（注意断言一个优化过早自身可能就是一个过早的优化）；
主动适应需求变更（不同时明确全部的具体需求，只限定需求范围：能使用计算机实现部分语义的任务）。

@1.4.2 阶段性目标：
确定系属分类。
确定实现方法。
必要的自然语言描述。
基础语义设计。
领域特定语言演化。

@1.4.3 语义方法：
形式语义方法：指称语义、公理语义、操作语义。
非确定语义：经验语义，不需要使用自然语言解释的部分。

@2 基本概念和约定：
描述中可能涉及上下文相关的略称参见 @2.3 。

@2.1 通用约定：
关于“语言”补充的基本概念和约定，使用元语言语法 <相关范畴/上下文> 。
除非有其它说明，适用于任意上下文。

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

@2.1.2 [<非自指>] ：
形式(form) ：参见经验语义和数学。
 <概念> 内涵：参见形式逻辑学。
 <概念> 外延：参见形式逻辑学。
 <概念> 定义(definition) ：确定概念内涵和外延的方法；参见任意一种形式逻辑学。
集合(set) ：参见 NBG 集合论。
序列(sequence) ：有序集合。
类(class) ：参见 NBG 集合论和范畴论。
真类(proper class) ：参见 NBG 集合论和范畴论。
 <动词> 抽象(abstracting) ：通过经验语义定义概念范畴或集合的方法。
 <名词> 抽象(abstraction) ：<动词>抽象的结果。
 <动词> 封装(encapsulating) ：从某一个范畴中抽象一个子范畴的方法。
 <名词> 封装(encapsulation) ：<动词>封装的结果。
接口(interface) ：一种封装，参见软件工程学。
实现(implementation) ：一种封装，参见软件工程学。
重用(reusing) ：参见经验语义和软件工程学。
不变量(invariable) ：满足某种等价关系的实体。参见数学和契约式程序设计。
状态(state) ：可以和其它实体关联的、可在某个上下文中保持变化或不变的实体。同一状态总是保持变化或保持不变。状态变化的含义参见经验语义、数学或另行约定。
可变状态(mutable state) ：在某个上下文中可能映射到若干其它状态的状态。
不可变状态(immutable state) ：不是可变状态的状态。
 <动词> 派生(deriving) ：基于重用的操作。
 <名词> 派生(derivation) ：<动词>派生的结果。
 <语言> 接口(<language>interface) ：和表达语义有关的语言的可见的特征。
 <语言> 实现(<language>implementation)：对于语言表达语义的表达。
 <语言> 人类接口(human interface) ：语义仅对人类有意义（内容改变时可以导致语义的差异性），不提供为涉及作为图灵机实现的语言接口。
 <语言> 机器接口(machine interface) ：对于机器（或特定语言实现的特定部分）有意义的语言接口。注意不同语言实现组成部分可以不同。例如，对于 C 预处理器而言， C 源代码中的空白符是机器接口，而对于翻译器来说则不是。就源代码而言，机器接口总是人类接口的子集。
语言特性(language feature) ：作为功能提供的人类接口。

@2.2 领域约定：
适用于上下文 <NPL> 。
广义实体： <通用约定> 实体。语言抽象的目标，不另行定义（意义最终取决于自然语言）。
名称(name) ：一种特殊的广义实体，用于指称另一个广义实体。
实体(entity) ：非名称的广义实体。
语言实现(language implementation) ：语言提供的接口的实现，是语言的表现形式，可以是具体语言实现或抽象语言实现之一。
具体语言实现(concreate language implementation) ：在机器上能够最终表达为指令流或其它形式表达可计算性的实现，一般应为程序。
抽象语言实现(abstract language implementation) ：非具体语言实现的语言实现。形式意义的标准定义的语言属于此类。
派生语言实现(derived language implementation) ：派生已有实现的部分或全部得到的语言实现。以下简作“派生实现”。
代码(code)：任意有限的语言的实例片段。
伪代码(pseudo code)：抽象语言实现的语言的代码。注意习惯上和具体语言实现代码完全一致的代码可以不作为伪代码考虑。
实现环境(environment of implementation) ：对应于特定语言实现的特定不变状态（对于机器来说可以是配置项，对于人来说不确定，所以一般忽略）的集合。
行为(behavior) ：语言实现的外部表现。基于可操作性考虑，一般仅约束机器实现。
规则(rule) ：用于确定行为的描述。
约束(constraint) ：可被形式表达，用于限制和明确行为的规则。不一定使用形式表达。
违反(violation) ：对约束指定的条件的不满足。
诊断消息(diagnostic message) ：用于和用户交互的提示性信息。
未定义的(undefined) ：可能导致违反约束但不保证具有诊断消息的。表示置于规则下的行为等不可预测。
未指定的(unspecified) ：在各个实现中可能存在的。不应假定不同实现具有完全一致的特性。
由实现定义的(implementation-defined) ：取决于各个具体实现的，要求有文档说明。
由派生实现定义的(derived-implementation-defined) ：取决于各个具体派生实现的，要求除存在默认定义或被派生实现的部分有明确的文档说明。
语言特性(language feature) ：语言提供的功能接口，可以是具体语言特性或抽象语言特性之一。
具体语言特性(concrete language feature) ：完全没有派生语言实现定义的语言特性。
抽象语言特性(abstract language feature) ：非具体语言特性的语言特性。
过时的(obsolesence) ：不应继续使用的（接口/特性）。
废弃的(deprecated) ：过时的但因为兼容性等暂时保留的、一般可提供替代的（接口/特性）。

@2.3 略称：
仅在不致混淆时使用。
实现(implementation) ：语言实现。
环境(environment) ：实现环境。
派生实现(derived implementation) ：派生语言实现。

@2.4 NPL 实现模型：
 NPL 是抽象的语言，没有具体语言实现(@2.2) ，但一些直接影响实现表现形式的规则被本节限定。

@2.4.1 实现的执行阶段(phase of execution) ：
 NPL 实现应保证行为能符合以下的阶段（具体阶段不要求和实际实现中的一一对应，但应保证顺序一致）：
词法分析：必要时转换字符编码；转义并提取记号。
语法分析：检验语法正确性(@2.5) 。
语义分析：检验语义正确性(@2.5) 。
代码生成：生成可被其它阶段执行的代码，称为目标代码。
运行：运行目标代码。
运行之前的阶段总称为翻译(translation) ，包含各个翻译阶段(phase of translation) 。
其中对于有宿主语言支持的嵌入实现(embedded implementation) 或目标不是程序的情况，代码生成及之后的阶段不是必须的。
嵌入实现的宿主语言可能直接运行语义分析的结果。
其它可能的阶段由派生实现定义，但应满足所有阶段具有确定的全序关系，且不改变上述指定的阶段的顺序。符合这些条件的附加阶段称为扩展阶段。

@2.4.2 并发实现(concurrent implementation) ：
一个实现中顺序执行以上执行阶段的控制流称为一个执行线程(thread of execution) ，简称线程(thread) 。
一个实现在整个执行过程中可以有一个或多个线程被执行。是否支持多线程执行（多线程翻译和/或多线程运行）由派生实现定义。

@2.4.3 阶段不变量约束：
若某些状态在某个执行阶段 k 被唯一确定为不可变状态，且在之后的状态下是不变量，则此状态称为满足 k 阶段不变量约束的。

@2.5 程序正确性：
正确性规则包含语法正确性和语义正确性。
当正确性规则被发现违反时，实现进入异常执行状态。
异常执行的实现是否存在未定义行为由派生实现定义。

@2.6 实现行为：
实现的行为由具有非特定存储的抽象机描述。
若语义规则明确可以行为被忽略，则被忽略之后的实现行为与之前等价。
允许派生实现定义附加的等价性。
实现可能向用户以派生实现定义的方式输出诊断消息(diagnostic message) 。

@3 文法：
本章约定 NPL 文法的基本规则，包括语法及对应的基础词法。文法对应的语义单独列为一章(@4) 。
多态文法规则：派生实现可完全不提供本章明确定义的词法和语法构造的支持，仅当提供同构的替代文法且符合语义规则。

@3.1 基本概念：
字符(character) ：组成语言代码的最小实体。
基本翻译单元(basic transation unit) ：任意连续字符的有限序列（可以是空序列）。
翻译单元(translation unit) ：基本翻译单元的集合，之间满足由派生实现定义的规则。

@3.2 字符集：
字符集(character set) ：对于一个实现而言不变的字符的有限集合。
基本字符集(basic character set) ：实现环境必须支持的字符集。具体由派生实现定义。
其它同 ISO/IEC 14882:2011 对 character 和 character set 的有关定义。

@3.3 词法：
约定元语言语法 <x> 表示词法元素 x ， ::= 表示定义， | 表示析取。
名称约定为在 NPL 中符合语法(@3.4) 约束的若干记号(@3.3.1) 的集合，一般可实现为可表达的字符串。

@3.3.1 基本词法构造：
 <token> ::= <literal> | <$punctuator> | <$identifier>
记号(token) ：代码中非空白符分隔的字符序列。
字面量(literal) ：一种记号，参见 @3.3.3 。
标点(punctuator) ：由派生实现定义的特定字符序列的集合，起分隔其它记号的作用，具有一定语义功能。
标识符(identifier) ：除字面量和标点以外的记号。
可以保证 ISO/IEC 14882:2011 的 identifier 的定义，或在上述标识符中插入字符 $ 构造得到的标识符属于 NPL 标识符。

@3.3.2 转义序列和字符序列：
 <char-escape-content-seq> ::= <$single-escape-char> | <$escape-prefix-char><$escape-content-seq>
 <char-seq> ::= <$literal-char> | \<char-escape-seq>

@3.3.3 字面量：
 <literal-content> ::= <char-seq> | <literal-char-seq><literal-data>
 <code-literal> ::= '<literal-content>'
 <data-literal> ::= "<literal-content>"
 <string-literal> ::= <code-literal> | <data-literal>
 <literal> ::= <string-literal> | <$derived-impldef-literal>
代码字面量(code literal) ：以 ' 作为起始和结束字符的记号。
数据字面量(data literal) ：以 " 作为起始和结束字符的记号。
字符串字面量(string literal) ：代码字面量或数据字面量。
字面量：字符串字面量或其它由派生实现定义的记号。

@3.3.4 词法分析规则：
输入翻译单元，输出记号序列。
输出规则（按优先顺序）：
断行连接：反斜杠之后紧接换行符的双字符序列视为续行符，会被删除；
反斜杠转义：连续两个反斜杠被替换为一个反斜杠；
引号转义：反斜杠之后紧接单引号或双引号时，反斜杠会被删除；
字面量：未被转义的单引号或双引号后进入字面量解析状态，无视以下规则，直接逐字节输出原始输入，直至遇到对应的另一个引号。
窄字符空白符替换：单字节空格、水平/垂直制表符、换行符被替换为单一空格；回车符会被忽略；
原始输出：其它字符序列逐字节输出。

@3.4 语法：
约定元语言语法 x 表示语法元素 x ， ::= 表示定义， | 表示析取。

@3.4.1 基本语法构造：

@3.4.2 表达式(expression) ：
 expression ::= atomic-expression | composite-expression | list-expression
表达式是受表达式语法约束的记号序列。
其中构成分别称为原子表达式(atomic expression) 、复合表达式(composite expression) 和列表表达式(list expression) 。

@3.4.2.1 原子表达式：
 atomic-expression ::= token
原子表达式不能被表示为其它表达式的语法构成形式的复合。

@3.4.2.2 复合表达式：
 composite-expression ::= token expression | expression token
符合表达式是原子表达式和表达式的复合。
同一个表达式可能被按原子表达式出现的位置以不同的方式规约为复合表达式。允许的规约复合表达式的方式由派生实现定义。

@3.4.2.3 列表表达式：
 list-expression ::= <left-list-bound> expression <right-list-bound>
 <left-list-bound> ::= ( | <extended-left-list-bound>
 <right-list-bound> ::= ) | <extended-right-list-bound>
列表表达式是使用 <left-list-bound> 和 <right-list-bound> 作为边界的表达式。
 <left-list-bound> 和 <right-list-bound> 是不同的标点。
边界为 ( 和 ) 的表达式是基本列表表达式。其它可能的边界由派生实现定义，构成扩展列表表达式。

@3.4.3 语句：
以派生实现定义的标点结尾的表达式称为语句。

@4 语义：

@4.1 基本概念：
范围(range) ：一个连续区间。此处“连续”的概念由派生实现定义，默认参照数学的形式定义。
声明(declaration) ：引入单一名称的表达式。
声明区域(declarative region) ：对于某一个声明及其引入的名称，通过声明区域规则(@4.3.1) 决定，可由词法分析实现(@5.3) 确定的关于这个名称有效的代码片段的最大位置范围。
有效名称(valid name) ：可以唯一确定指称的实体的名称。
有效命名实体(valid named entity) ：有效名称指称的实体。
名称隐藏(name hiding) ：若同一个名称在同一个位置属于超过一个声明区域，则应能通过名称隐藏规则(@4.3.2) 确定唯一有效的声明以指定有效名称和对应的有效命名实体，此时有效名称隐藏其它声明区域声明的名称，有效命名实体隐藏可以使用被隐藏名称指称的实体。
作用域(scope) ：声明区域的子集，满足其中指定的名称是有效名称。
生存期(lifetime) ：逻辑上关于可用性的连续区间的抽象，是一个闭集。
对象(object) ：表示可被逻辑上表达为连续存储的状态的集合且能明确生存期开始和终止的实体。
变量(variable) ：通过声明引入的实体。注意不一定表示可变状态。
常量(constant) ：满足某种不变量的约束以和不可变状态关联的实体。具体由派生实现定义。注意不和变量对立（表示不可变状态的变量可能是常量）。
值(value) ：表达式关联的不可变状态。
副作用(side effect) ：对作为实现环境的状态的改变。
求值(evaluation) ：实现对表达式的处理过程，包括值的计算和副作用的产生。
规约(reduction) ：以表达式替代另一个表达式的过程。

@4.1.1 覆盖约定：
状态的不变性由派生实现定义的等价规则指定，默认为能定义等价类的相等运算。

@4.2 基本语义规则：
所有不需要诊断消息的规则由派生实现定义（即以下规则不产生未定义行为）。

@4.3 名称规则：
名称(@2.2) 是一个表达式(@4.4.1) 。
特定的由派生实现定义的表达式是一个名称(@2.2) ，通过名称查找确定唯一指称的实体。

@4.3.1 声明区域规则：
对于引入名称 n 的声明 D ，对应的声明区域起始于紧接 n 的位置，终止于满足以下条件的记号“)”（若存在）或翻译单元末尾（不存在满足条件的记号“)”）：
记号“)”和与之匹配的记号“(”构成的表达式包含 D ；
此记号之前不存在满足上一个条件的其它的记号“)”。

@4.3.2 名称隐藏规则：
若声明 D 是表达式 E 的子集，且不存在 D 的子集声明同一个名称，则 D 声明了有效名称，隐藏了 E 中其它同名的名称。

@4.3.3 名称查找(name lookup)：
名称查找是从已知有效名称确定唯一指称的实体的过程。
不保证名称查找总是成功。
名称查找的具体规则由派生实现定义。
不同名称经过名称查找的结果可能等效。等效的有效名称视为同一的，规则由派生实现定义。

@4.3.4 命名空间(namespace) ：
命名空间是实体(@2.2) 。命名空间可以由名称指称。

@4.3.4.1 指称：
总是没有名称指称的命名空间是匿名命名空间(anonymous namespace) 。
没有有效名称指称的命名空间是未命名命名空间(unnamed namespace) 。
注意匿名命名空间和未命名命名空间不同。前者可能是一个系统的默认约定，一般整体唯一存在（如全局命名空间）；后者只是对某些接口隐藏，可以有多个。
 NPL 定义一个抽象的匿名命名空间，称为根命名空间。未命名命名空间的支持由派生实现定义。
 NPL 约定一个在实现中的有效名称总是指称一个命名空间。有效名称指称的命名空间的同一性和有效名称的同一性(@4.3.3) 对应。

@4.3.4.2 成员：
除了用于指称的名称外，一个命名空间可以和若干其它名称关联。
通过派生实现定义的对命名空间的操作可以取得的名称是这个命名空间的成员。
若无歧义，命名空间的成员指称的实体也称为这个命名空间的成员。
命名空间直接包含成员，称为直接成员。
除了根命名空间和其它派生实现定义外，命名空间可以作为另一个命名空间的成员，此时命名空间内的成员（若存在）是包含其的命名空间的间接成员。
命名空间对成员的直接包含和间接包含总称为包含，是反自反的、反对称的、传递的二元关系。

@4.3.4.3 简单名称(simple name) 和限定名称(qualified name) ：
命名空间的直接成员(@4.3.4.2) 的标识符在这个命名空间中是有效名称，称为简单名称。
命名空间及其成员按包含关系依次枚举标识符组成的序列是一个名称，称为在这个命名空间中的限定名称。
根命名空间的限定名称称为全限定名称(fully qualified name) 。
限定名称的语法（如标识符之间的分隔符等）由派生实现定义。

@4.4 求值规则：
除了应满足的本节约定的最小求值规则和语义外的具体求值规则和语义由派生实现定义。
派生实现的求值可以满足以下节约定的规则。

@4.4.1 规范形式：
规范形式是由派生实现定义的一类抽象的实体，可以和语法形式对应，同时反映实现的状态。
规范形式和终止求值的表达式对应，同时直接确定地对应一个值(@4.1) 。具有规范形式的表达式具有值。
派生实现可以指定某些表达式不保证具有强规范化，即不保证能最终确定对应的规范形式，它的求值不保证总是能终止。

@4.5 λ 完备语义和对应语法：
作为通用语言，求值规则表达的系统可具有和无类型 λ 演算(untyped lambda calculus) 对应的形式和计算能力。
基于此语义的派生实现应允许以下几种互不相交的表达式集合，且保证满足在派生实现定义的项上的强规范化（即保证求值能终止）。

@4.5.1 名称表达式(name expression) ：
名称表达式是表示变量的 λ 项。
原子表达式(@3.4.2.1) 的由派生实现定义的非空子集是名称表达式。其它作为名称表达式的表达式语法形式由派生实现定义。

@4.5.2 函数(function) ：
特定的由派生实现定义的表达式对应于 λ 抽象，称为函数表达式，简称函数。
 λ 抽象可以捕获(capture) 若干有效名称及对应的实体，即这些名称可在函数中使用。
被捕获的名称指称的实体是函数的形式参数(formal parameter, parameter) 。
表达式外被捕获的名称指称的实体是实际参数(actual argument, argument) 。
实际参数和形式参数一一对应。
派生实现应在仅有名称表达式不同的两个函数之间定义等价规则，以满足 λ 演算的 α-转换(alpha-conversion) 规则。

@4.5.3 函数应用：
形如 E1 E2 的表达式 E ，当且仅当 E1 是函数时， E 是函数应用表达式，简称函数应用。
函数应用符合 λ 演算的 β-规约(beta-reduction) 规则。
派生实现应指定函数应用规约(@4.1) 的结果是规范形式(@4.5.2)，它对应的值称为函数值。

@4.6 表达式关联实体：

@4.6.1 上下文(context) ：
上下文是表达式关联的状态的特定集合（注意不是 @2.1.1 约定的自指概念），包含以下小节约定的类别。
确定上下文的状态或对可变上下文的修改称为对上下文的访问(access) 。
具体由派生实现定义。

@4.6.1.1 显式上下文(explicit context) ：
可通过名称表达式(@4.1.5) 访问的上下文。

@4.6.1.2 隐式上下文(implicit context) ：
除显式上下文外的上下文。

@4.6.2 类型(type) ：
上下文中和表达式直接关联或间接关联的元素，满足某个执行阶段的不变量约束(@2.4.3) 。
和表达式直接关联的类型满足起始阶段不变量约束，称为静态类型(static type) 。
和表达式的值(@4.1) 关联的类型满足运行阶段(@2.4.1) 的不变量约束，称为动态类型(dynamic type) 。
其它可能存在类型或实现执行阶段的扩展由派生实现定义。
称为类型的具体实体和之间的关联由派生实现的类型系统(type system) 规则指定。

@5 语言实现：
当前维护的派生语言为 NPLA ，是 NPL 的抽象语言实现，约定以下附加规则。
 NPLA 的参考实现 NPLA1 是具体语言实现，约定特定于当前参考实现的附加规则和实现。

@5.1 NPLA 领域语义支持：
位(bit) ：表示二进制存储的最小单位，具有 0 和 1 两种状态。
字节(byte) ：基本字符集中一个字符需要的最少的存储空间，是若干位的有序集合。
八元组(octet) ： 8 个位的有序集合。

@5.2 NPLA 约定：
一字节至少占用 8 个二进制位。
只支持左原子表达式构成复合表达式(@3.4.2.2) 。
只支持基本列表表达式(@3.4.2.3) 。
名称可被实现为字符串。
动态类型同静态类型。

@5.3 NPLA1 约定：
一字节占用 8 位。
翻译单元同基本翻译单元。
字面量同字符串字面量。
标点为单字节序列。
名称仅被实现为字符串。
不支持语句(@3.4.3) 。
 NPLA1 是以 ISO C++11 为宿主语言的嵌入实现，不包含扩展执行阶段(@2.4.1) 。
 NPLA1 单一实现不支持多线程执行(@2.4.2) ，但允许多个实现同时在宿主中多线程执行。
 NPLA1 的规范形式是特定类型的 C++ 对象，使用 YSLib::ValueNode 作为多个阶段的规范形式(@4.4.1) 的实现。
仅使用宿主语言的类型和值作为状态。类型等价性由 C++ 定义。值等价性由宿主实现的 == 表达式的结果定义。
当前不特别约定类型系统，所有类型都是同宿主类型的空字符结尾的字符串（ C++ NTCTS ）。

@5.4 NPLA1 词法分析实现：
参见 @3.3.4 和参考实现 NPL::Lexical 。

@5.5 NPLA1 语法分析实现：
派生实现可能检查更多语法规则。
抽象语法树以 YSLib::ValueNode([Documentation::YSLib @@3.16]) 表示。

@5.6 NPLA1 附加名称规则：
当前仅支持标识符作为名称。

@5.7 NPLA1 附加求值规则：
当前要求函数是名称。
函数的求值结果被宿主实现以 YSLib::ValueNode 表示为 YSLib::string 类型或 YSLib::ValueNode 类型的节点。

@5.8 应用实例：
 NPLA1 当前加入特定的序列化和反序列化作为配置文件，参见 NPL::Configuration 。
 NPLA1 的上述配置文件加入特定的匹配和初始化机制作为 YSLib::UI::Loader([Documenatation::YSLib @@5.6.8]) 在运行时读取用户界面布局和配置的脚本。
 NPLA1 用于 MIME 类型和文件名映射([Documentation::YSLib @@4.6.3]) 的实现，上述配置文件对应的外部配置格式。

@5.9 兼容性：
 b449 增加对多个未命名节点（叶节点或首个子节点未能解析为名称的分支节点）作为非名称子节点时的反序列化支持。多个值会被以 $ 前缀接序号（从 0 起始）命名。之前的版本中读取的节点名称为空串，值被覆盖为第一个节点值。

@6 编码风格导引：
仅叙述之前章节未涉及的内容。
参见 [Documentation::CommonRules @@6] 。

@7 一般实现导引：

@7.1 程序实现：
程序是语言的派生。实现程序即在语言的基础上指定派生规则。

*/
////

