refactor(include): refactor the porting-interface

1. refactor the porting-interface and use hash-map instead of trie
2. change some detailed code
3. optimize the project
please refer to the work log for details

Author: CLimber-Rong

.clang-format

@@ -56,7 +56,7 @@ BreakConstructorInitializersBeforeComma: false
 BreakConstructorInitializers: BeforeComma
 BreakAfterJavaFieldAnnotations: true
 BreakStringLiterals: true
-ColumnLimit: 81
+ColumnLimit: 80
 CommentPragmas: '^ IWYU pragma:'
 CompactNamespaces: false
 ConstructorInitializerAllOnOneLineOrOnePerLine: false
@@ -95,7 +95,7 @@ PenaltyBreakBeforeFirstCallParameter: 300
 PenaltyBreakComment: 500
 PenaltyBreakFirstLessLess: 400
 PenaltyBreakString: 600
-PenaltyExcessCharacter: 1000
+PenaltyExcessCharacter: 100000
 PenaltyReturnTypeOnItsOwnLine: 300
 PointerAlignment: Right
 ReflowComments: true

Makefile

@@ -5,7 +5,8 @@ UPX = upx
 REMOVE = del
 
 STD = c++17
-LINK = 	-I include/stdc_implemented \
+LINK = 	-I include/interface \
+		-I include/stdc_implemented \
 		-I src/ast \
 		-I src/data_type \
 		-I src/vm \
@@ -77,7 +78,7 @@ zip_release_win:
 	$(UPX) --best --lzma bin/stamon.exe
 
 zip_release_linux:
-	$(UPX) --best --lzma bin/stamon.exe
+	$(UPX) --best --lzma bin/stamon
 
 zip_release_macos:
-	$(UPX) --best --lzma bin/stamon.exe
+	$(UPX) --best --lzma bin/stamon

README.md

@@ -6,7 +6,7 @@
 
 * CLimber-Rong在2023年二月份开发了简陋的第一代Stamon。在2023年7月份，CLimber-Rong决定开发第二代——Stamon2（以下简称Stamon）
 * Stamon是一门面向对象的动态编程语言。
-* Stamon可移植性极高，只需要实现为数不多的依赖库，Stamon就可以在你的平台上运行。
+* Stamon可移植性极高，只需要实现为数不多的移植接口，Stamon就可以在你的平台上运行。
 
 ## 下载发行版
 
@@ -38,8 +38,6 @@
 
 本项目已加入开源项目保护宣言（MOSPP），我们建议开发者们遵守此宣言所倡导的开源精神（当然，这**只具有道德约束力**）。
 
-为了防止本项目遭受学术抄袭，我们决定暂时采用异步更新：发行一个版本时，先发行可执行文件，再下一次版本更新时才推送此版本的源码（即源码始终比可执行文件慢一步发布）。
-
 ## 开发者
 
 * CLimber-Rong [Github主页](https://github.com/CLimber-Rong) [Gitee主页](https://gitee.com/QuXiangrong)

doc/CITP设计文档.md

@@ -0,0 +1,197 @@
+# CITP设计文档
+
+### 摘要
+
+在C++中，前人已经提出了多种约束接口的方式。其中，CRTP不妨是一个适用于低标准且不需要性能的静态多态设计方式。但CRTP无法约束构造函数，实现过程涉及静态转换，代码复杂。为此，我们提出了CRTP的变式——**CITP**（**Curiously Iterating Template Pattern，奇异递推模板模式**），并将其首次应用到Stamon当中。
+
+### 需求性分析
+
+我们先来引入一段典型的CRTP设计：
+
+```C++
+/* 例1 */
+#include <iostream>
+using namespace std;
+
+template<class Impl>
+class Constraint {
+	public:
+	int square(int x) {
+        // 被开发者调用的接口
+		return static_cast<Impl*>(this)->square(x);
+        // 静态转换为Implementation，并调用其实现，实现接口约束
+	}
+};
+
+class Implementation : public Constraint<Implementation> {
+	public:
+	int square(int x) {
+        // Constraint::f(int)的实现
+		return x*x;
+	}
+};
+
+using Square = Implementation;
+
+int main()
+{
+  	Square s;
+	cout<< s.square(5) <<endl;    // 运行结果：25
+	return 0;
+}
+```
+
+以上设计存在以下缺陷：
+
+* 使用特殊的模板递归形式，学习成本高，难以理解
+* 将this静态转换为子类并调用，实现复杂
+* 无法安全地对构造函数进行约束
+
+导致以上缺陷的原因如下：
+
+* 用父类约束子类，又将子类作为类型参数传递给父类，产生奇异递归
+* 在父类中调用子类的成员，需要进行静态转换
+* 构造函数一般自底而上调用，因此父类无法简便地约束构造函数
+
+在经过大量地实验性设计后，我们综合了代理模式等设计模式，提出了一种可以解决以上缺陷的方案：与CRTP将用于接口约束的类作为父类的做法相反，我们将用于接口约束的类作为子类，受约束的类作为父类，从而让接口约束从递归变为递推。
+
+这种方案具有以下优点：
+
+* 不需要复杂的递归形式
+* 让受约束的父类被子类调用，鉴于子类可以安全调用父类成员，用于约束的类无需静态转换
+* 用于约束的子类在构造时可以将构造函数完美转发给受约束的父类
+
+综上所述，在某些情景下，CITP能比CRTP约束更多东西，且能减少思维量。
+
+### 设计
+
+我们来看看 _例1_ 在CITP中的设计：
+
+```C++
+/* 例2 */
+#include <iostream>
+using namespace std;
+
+class Implementation {
+	// 实现类作为父类受约束
+	public:
+	int square(int x) {
+		// 受约束接口
+		return x*x;
+	}
+};
+
+template<class Impl>
+class Constraint : public Impl {
+	// 用于约束的类作为子类，继承实现类
+	public:
+	int square(int x) {
+		// 调用Impl的实现
+		return Impl::square(x);
+	}
+};
+
+using Square = Constraint<Implementation>;
+// 将Implementation传递给Constraint作为约束
+
+int main()
+{
+  	Square s;
+	cout<< s.square(5) <<endl;    // 运行结果：25
+	return 0;
+}
+```
+
+在 _例2_ 中，我们将Constraint作为一个模板类，并使其继承模板提供的类，因此Constraint可以完美的调用其父类（即受约束的类）的成员，包括构造函数。开发者在实现时应使用using关键字给Constraint<Implementation>赋予供用户使用的别名（例如 _例2_ 的Square）。
+
+我们再看看在CITP中，如何约束构造函数：
+
+```C++
+/* 例3 */
+#include <iostream>
+using namespace std;
+
+class Implementation {
+	// 实现类作为父类受约束
+	int k, b;
+	public:
+	Implementation(int K, int B) : k(K), b(B) {};
+	int f(int x) {
+		// 受约束接口
+		return k*x + b;
+	}
+};
+
+template<class Impl>
+class Constraint : public Impl {
+	// 用于约束的类作为子类，继承实现类
+	public:
+	Constraint(int K, int B) : Impl(K,B) {};
+	int f(int x) {
+		// 调用Impl的实现
+		return Impl::f(x);
+	}
+};
+
+using Linear = Constraint<Implementation>;
+// 将Implementation传递给Constraint作为约束
+
+int main()
+{
+  	Linear l(4,5);
+	cout<< l.f(5) <<endl;    // 运行结果：25
+	return 0;
+}
+```
+
+可以看到，Constraint只需要正常编写构造函数，并转发给父类的构造函数，即可实现构造函数的约束。此外，由于析构函数的调用顺序是从子类到父类，因此Constraint哪怕没有编写析构函数，Implementation的析构函数也照样会被正常调用。但这也使得析构函数无法收到约束——CITP难以保证受约束的类一定拥有开发者手写的析构函数。
+
+CITP的设计中，约束重载运算符的方式和约束普通方法的方式是不同的。我们将 _例3_ 中的函数``int f(int)``改装成``int operator<<(int)``，来看看CITP是如何约束重载运算符的：
+
+```C++
+/* 例4 */
+#include <iostream>
+using namespace std;
+
+class Implementation {
+	// 实现类作为父类受约束
+	int k, b;
+	public:
+	Implementation(int K, int B) : k(K), b(B) {};
+	int operator<<(int x) {
+		// 受约束接口
+		return k*x + b;
+	}
+};
+
+template<class Impl>
+class Constraint : public Impl {
+	// 用于约束的类作为子类，继承实现类
+	public:
+	Constraint(int K, int B) : Impl(K,B) {};
+	int operator<<(int x) {
+		// 调用Impl的实现
+		return Impl::operator<<(x);
+	}
+};
+
+using Linear = Constraint<Implementation>;
+// 将Implementation传递给Constraint作为约束
+
+int main()
+{
+  	Linear l(4,5);
+	cout<< (l<<5) <<endl;    // 运行结果：25
+	return 0;
+}
+```
+
+### 结论
+
+CITP相较于CRTP，更专注于接口约束，是一个适用于低C++标准的高性能方案。但CITP目前仍然存在缺陷：
+
+* 无法具体约束函数的行为，也无法约束析构函数
+* 在传递参数、返回值时也可能发生参数、返回值的隐式转换且无法约束这种转换
+* 如果CITP模板代码处于未使用状态，编译器可能不会进行接口约束检查
+
+这些问题正在研究当中，有待解决。

doc/SFN机制文档.md

@@ -43,20 +43,23 @@ void sfn_print(SFN_PARA_LIST);
 
 ##### 实现外部函数
 
-外部函数可以使用依赖库上的函数，对于移植在平台上的开发者而言，也可以引入更多平台特有的函数进行操作。外部函数应该使用``stamon::exception::sfn::SFNError``作为异常生成函数，开发者也可以引入更多细化的异常生成函数。
+外部函数可以使用移植接口上的函数，对于移植在平台上的开发者而言，也可以引入更多平台特有的函数进行操作。外部函数应该使用``stamon::exception::sfn::SFNError``作为异常生成函数，开发者也可以引入更多细化的异常生成函数。
 
 ``sfn_print``的实际实现如下：
 
 ```C++
 void sfn_print(SFN_PARA_LIST) {
+
+	using namespace stamon;
+
 	STMException *ex = sfn.ex;
-	stamon::datatype::DataType *val = arg->data;
-	if (val->getType() != stamon::datatype::StringTypeID) {
-		THROW(stamon::exception::sfn::SFNError(
+	datatype::DataType *val = arg->data;
+	if (val->getType() != datatype::StringTypeID) {
+		THROW(exception::sfn::SFNError(
 				"sfn_print()", "invalid type"));
 		return;
 	}
-	platform_print(((stamon::datatype::StringType *) val)->getVal());
+	platform_print(((datatype::StringType *) val)->getVal());
 	return;
 }
 ```
@@ -81,4 +84,4 @@ SFN(STMException *e, vm::ObjectManager *objman) {
 }
 ```
 
-``sfn_functions``是一个``StringMap``，存储的值类型是符合外部函数原型的函数指针。在构造函数中加入利用``sfn_functions.put``来指定端口号及其对应的外部函数
+``sfn_functions``是一个Map，存储的值类型是符合外部函数原型的函数指针。在构造函数中加入利用``sfn_functions.put``来指定端口号及其对应的外部函数

doc/代码速览指南.md

@@ -1,4 +1,8 @@
-# 代码速览指南（第三版）
+# 代码速览指南（第四版）
+
+### 第四版前言
+
+进一步优化了表达方式，将源码目录功能和阅读顺序统一为一个表格。
 
 ### 第三版前言
 
@@ -23,7 +27,7 @@
 
 * 文件后缀
 
-本项目中，依赖库的源码后缀统一为``.h``或``.hpp``格式；主体实现部分中，每一个源码子目录由一个``.hpp``文件来统领其他的``.cpp``文件（要求开发者只需包含此``.hpp``文件即可调用该子目录下的所有代码）。
+本项目中，移植接口的源码后缀统一为``.h``或``.hpp``格式；主体实现部分中，每一个源码子目录由一个``.hpp``文件来统领其他的``.cpp``文件（要求开发者只需包含此``.hpp``文件即可调用该子目录下的所有代码）。
 
 ``.hpp``和``.cpp``都可以用于代码的定义和实现，两个后缀名在本项目当中仅用来区分哪个文件统领了源码目录。
 
@@ -33,43 +37,26 @@
 
 由于本项目并未采用“定义与实现分离开来，后期统一链接”的形式。
 
-我们不建议开发者将此项目中的``#include``看作C/C++中的包含，而是看作import（类似java，py的设计）。
+我们不建议开发者将此项目中的``#include``看作C/C++中的包含，而是看作import（类似java，python的设计）。
 
 因为本项目的编译指令只有一条，不存在链接，因此我们不建议两个文件之间相互包含（请尽量编写不循环引用的代码）。
 
-### 项目架构
+### 项目架构及源码阅读顺序
 
 我们来介绍与源码有关的目录：
+我们将用一个表格来解释每个目录的用途。目录从顶至底，也是推荐的源码目录阅读顺序。
 
 |目录名|用途|
 |:-|:-|
-|``include``|该目录用于存放依赖库文件，此目录又有多个子目录。其中``template``子目录用于存放依赖库模板，其余子目录是依赖库的不同平台实现。|
-|``src``|该目录存储主体实现部分的代码，与依赖库实现分割开来，以此实现更强的可移植性。该目录下存放有若干子目录和项目主要文件（例如程序的入口源码）。|
+|``include``|该目录用于存放移植接口的定义和不同方法的实现，此目录又有多个子目录。其中``interface``子目录用于存放移植接口的定义，其余子目录是移植接口的不同方法实现。移植接口的更多介绍位于``移植接口开发指导.md``|
 |``src/ast``|该目录存储抽象语法树（AST）的数据结构，主要用于语法分析。|
-|``src/data_type``|该目录存储stamon数据类型的数据结构。|
-|``src/bin-include``|该目录存储Stamon的标准库源码。|
-|``src/exception``|该目录存储报错信息的生成函数。|
 |``src/config``|该目录存储程序运行的默认配置参数。|
+|``src/exception``|该目录存储报错信息的生成函数。|
 |``src/compiler``|该目录存储编译器的实现。|
-|``src/ir``|该目录存储Stamon的中间代码数据结构，中间代码生成器以及解析器。|
-|``src/sfn``|该目录存储Stamon调用虚拟机外部库的实现。|
+|``src/data_type``|该目录存储stamon数据类型的数据结构。|
 |``src/vm``|该目录存储虚拟机的实现。|
+|``src/sfn``|该目录存储Stamon调用虚拟机外部库的实现。|
+|``src/ir``|该目录存储Stamon的中间代码数据结构，中间代码生成器以及解析器。|
 |``src/action``|该目录用于存储分步行动机制的实现代码（包括一些文件的编解码实现）。|
-
-### 源码阅读顺序
-
-我们建议开发者先从基础出发，一步步看到主函数的实现。
-
-因此一个合理的源码阅读流程是（以目录为单位）：
-
-* ``include``
-* ``src/ast``
-* ``src/config``
-* ``src/exception``
-* ``src/compiler``
-* ``src/vm``
-* ``src/sfn``
-* ``src/action``
-* ``src/ir``
-* ``src``
-* ``src/bin-include``
+|``src``|该目录存储主体实现部分的代码，与移植接口实现分割开来，以此实现更强的可移植性。该目录下存放有若干子目录和项目主要文件（例如程序的入口源码）。|
+|``src/bin-include``|该目录存储Stamon的标准库源码。|