Unilang

　　本仓库维护名为 Unilang 新编程语言，包括相关的文档和参考实现——一个解释器。

　　解释器的构建和使用参见以下各节。

关于新语言

　　Unilang 是为适应更有效和灵活开发桌面环境应用的提出的通用目的编程语言项目。

特色

　　Unilang 是为了统筹解决现有不足的新的方案中的语言部分，主要特色有：

作为动态语言，提供相对其它语言更强的语言层次上的可扩展性。
- 大多数语言中需要修改语言核心规则提供的特性，在 Unilang 中预期只需要用户使用 Unilang 语言编写的库解决，例如静态类型检查可以通过用户程序提供。
  - 通过用户定制语言的功能，可以有效限制非预期的动态特性， 最终得到和大多数静态语言接近的开发体验上的优势，同时避免静态语言核心规则带来的不便 。
  - 允许在已部署 Unilang 程序的环境中通过添加库补全现有语言特性，而不需要重新部署工具链的实现。
  - 提供一个基础语言，并以库的形式扩展这个语言而得到实用的特性集。库预期由本项目和用户提供。
- 类似 C 和 C++ 而不同于 Java ，不明确要求或假定翻译和执行的具体形式。实现使用编译、解释和何种映像格式加载等实现细节对核心语言规则透明。
- 不预设如 C 和 C++ 那样明确的翻译阶段(phases of translation) 。不需要单独阶段展开的宏——配合支持一等环境的函数即可取代宏。
- 支持同像性(homoiconicity) ，允许代码即数据(code as data) 的方式编程。
- 函数是一等对象(first-class object) 。
- 环境(environment) 对变量绑定具有所有权。支持作为一等对象的一等环境(first-class environment) 。
支持类似 C++ 的对象模型和（当前不被检查的）不安全所有权语义。
- 和 C# 或 Rust 等不同，不提供一种特设的 unsafe 关键字标记“不安全”的代码段落，最基础的特性默认是“不安全”的。
- 安全性并非由语言唯一地定义，允许用户通过扩展类型系统等方式实现自定义的不同种和程度的安全性。
不要求全局 GC ，同时语言的一个子集允许和 C++ 同等层次的“不安全”但能确保确定性的资源分配。
- 没有原生提供针对不安全操作的静态检查，但是语言的可扩展性允许直接实现类型系统或者自动证明更强的内存安全。未来可能作为库一并提供。
- 语言规则仍然允许引入依赖 GC 的互操作。特别地，允许引入多个非全局的 GC 示例。
支持正式意义上的 PTC ，而不需要用户程序内对栈溢出等未定义行为进行变通。
- 主流语言中，没有依赖全局 GC 的语言实现都没有提供类似的保证。
使用隐式的潜在类型(latent typing) 而非显式的清单类型(manifest typing) 。
- 这自然地避免用户扩展的类型系统和原生规则冲突，而保持可扩展性。
  - 在扩展前，作为实现细节，已允许蕴含类型推断(type inference) 消除一些类型检查而不影响程序语义。
  - 允许用户程序扩展类型标注(type annotation) 的语法和相关检查。
- 表达式和 C++ 类似但略有不同的值类别(value category) ；但和 C++ 不同，不是静态确定的表达式的属性，而是跟随对象的动态元数据。
- 类似 C++ 的 const 类型限定符，通过左值引用的对象允许标记为不可修改（只读），而不是如 Rust 等语言默认约定值不可变(immutable) 。
- 类似 C++ 的消亡值(xvalue) ，通过左值引用的对象允许标记唯一，而允许其中的资源被转移。
原理以上代表性的选型决策中，一个共通的方法是比较不同方向的扩展之间的技术可行性——并选取容易扩展的选项。否则，即便可行，也有许多本应避免的无效的工作。
- 设计一个静态语言，然后添加一些规则把它伪装成具有足够动态特性的动态语言，远远难于在动态语言上添加规则而得到静态语言的特性集。
  - 因此，基础语言首先被设计为动态语言。
- 从一个标记放弃某种保证的上下文中添加证明恢复某种保证（且不和其它保证冲突），比从一个已知不具有保证的上下文添加证明以确保保证更困难。
  - 例如，用 unsafe 等特设语法标记“不安全”的语言中，通常会放弃语言定义的任意安全保证，而不能选择保留其中的一部分。即便忽略这个问题，语言也缺乏机制允许用户提供更严格的保证。
    - 因此，基础语言默认是不安全的。
  - 再如，默认不可变的数据结构虽然能保证 const correctness 这样的“正确性”（一种保持被限定的不可变性质不被丢弃的类型安全性(type safety)），却忽略对“不可变”的定义描述不充分而不能让用户程序扩展的问题——很多情形下，不可变仅仅需要是一种等价关系，而并非不可修改。
    - 这可能导致具体的不可修改性被滥用，例如 C++ 标准库关联容器的键类型实际上不需要符合 C++ 的 const ，因为键的不可变确切地由比较关系导出的等价关系定义，但类型系统无法区别两种情形。这过度地限制了键上的本应允许的操作。
      - 这里用 const_cast 这样的不安全转换取消 const 引入的类型安全保证并自行假定不会破坏不可变性，是个无奈的变通（“更困难”的情形，且无法恢复类型安全性而效果更差）。
    - 默认不可变的类型系统，如 Rust 的设计，则更根本地在类型组合构造上阻止了扩展的方向。
      - 这蕴含不可变性只有一种，除非修改类型系统设计，放弃原有的不可变定义并重新引入类似 C++ const 的限定符机制（“更困难”的情形）。
    - 这也限制了现有的实现的常量传播(const propagation) 的优化范围，因为原则上这里的“常量”只关心替换能保持变换前后的语义等价性(semantic-preserving) ，而不在意具体的值是否相等。
      - 若语言允许用户表达“一些具有不同表示的值被视为等价”，则优化的适应性会自然地扩展。
    - 因此，基础语言中的对象默认可变。
- 在一个已经要求全局 GC 的语言中排除 GC ，远远难于在不依赖 GC 的语言规则基础上添加和 GC 交互的能力（特别是 GC 允许用户定制时）。
  - 因此，语言首先排除对全局 GC 的依赖。
- 在一个没有 PTC 保证的语言实现中添加扩展基本是不可行的，除非重新实现最核心的求值规则在内的逻辑（例如，再添加一个执行引擎）。
  - 因此，语言首先要求 PTC 以使其实现有足够的可用性，而不鼓励嵌套的不可靠的实现。
  - 注意对 PTC 不可靠的实现方式在其它方面仍可能很成功（如翻译 ECMAScript 方言的 Babel ）。因此，大多数其它特性并没有（也不需要有）如 PTC 需要基本规则明确担保的地位。
和 C++ 具有良好的互操作性。
- 当前解释器（运行时）使用 C++ 实现。
- 结合对象模型，能确保 Unilang 对象和 C++ 对象的对应。
- 语言绑定主要关注已知 ABI 的 C/C++ API 。