IT之家 9 月 12 日消息，有IT之家网友发现，广度开放源码街道社区之前已经在 Github 和 gitee 发布了旗下暗鞘编程词汇 ——Unilang，与此同时还包括相关正则表达式，传授了 Unilang 文件格式和参照与此同时实现形式。
非官方在库中的描述是“新编程词汇”，是“为适应更有效率和灵巧合作开发GNOME应用领域的明确提出的通用型目地编程词汇工程项目”，意在更好地帮助当前图形界面应用领域合作开发人员，寄主自然环境为 MSYS2 MinGW32 和 Linux。
据悉，广度项目组由于 C / C++、ECMAScript 等最流行的许多技术标准词汇具备沉重的历史本钱，且不具备足够扩充词汇自身的能力以兼具其市场需求；Dart 等专门针对类似于初步设计的词汇在许多基本设计上的重大决策（如倚赖自上而下 GC ）使之无法完全适合许多重要情景；其他的许多通用型目地词汇，如 Rust 和 Go ，并没有基础建设明确提出 GUI 化解方案。
因此，他们希望在能满足市场需求的基础上，增添一种捷伊语言，使它能以更真切的形式真正地与此同时实现通用型性 —— 透过减少为部分问题领域准备的原生植物的专设的 (ad-hoc) 优点，而以更普遍的基本上优点集原本的形式。
Unilang 是为了统筹规划化解原有不足的捷伊方案中的词汇部分，主要特色有：
作为静态词汇，提供更多相对其他词汇大列佩季哈区的词汇层级上的可扩充性。
透过使用者订制词汇的功能，能有效率限制非市场预期的静态优点，最终获得和绝大多数静态词汇接近的合作开发新体验上的优势，与此同时避免静态语言核心理念准则增添的诸多不便。
允许在已部署 Unilang 程序的自然环境中透过加进库Bazelle原有词汇优点，而不须要布署工具链的与此同时实现。
提供更多一个基础词汇，并以库的形式扩充这个词汇而获得新颖的优点集。库市场预期由本工程项目和使用者提供更多。
绝大多数词汇中须要修改词汇核心理念准则提供更多的优点，在 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) ，透过左值引用的对象允许标记唯一，而允许其中的资源被转移。
原理 以上代表性的选型重大决策中，一个共通的方法是比较不同方向的扩充之间的技术可行性 —— 并选取容易扩充的选项。否则，即便可行，也有许多本应避免的无效的工作。
因此，词汇首先要求 PTC 以使其与此同时实原有足够的可用性，而不鼓励嵌套的不可靠的与此同时实现。
注意对 PTC 不可靠的与此同时实现形式在其他方面仍可能很成功（如翻译 ECMAScript 方言的 Babel ）。因此，绝大多数其他优点并没有（也不须要有）如 PTC 须要基本上准则明确担保的地位。
因此，词汇首先排除对自上而下 GC 的倚赖。
例如，用 unsafe 等专设语法标记“不安全”的词汇中，通常会放弃词汇定义的任意安全保证，而不能选择保留其中的一部分。即便忽略这个问题，词汇也缺乏机制允许使用者提供更多更严格的保证。
再如，默认不可变的数据结构虽然能保证 const correctness 这样的“正确性”（一种保持被限定的不可变性质不被丢弃的类型安全性 (type safety)），却忽略对“不可变”的定义描述不充分而不能让使用者程序扩充的问题 —— 很多情形下，不可变仅仅须要是一种等价关系，而并非不可修改。
因此，基础词汇默认是不安全的。
若词汇允许使用者表达“许多具备不同表示的值被视为等价”，则优化的适应性会自然地扩充。
这蕴含不可变性只有一种，除非修改类型系统设计，放弃原有的不可变定义并重新引入类似于 C++ const 的限定符机制（“更困难”的情形）。
这里用 const_cast 这样的不安全转换取消 const 引入的类型安全保证并自行假定不会破坏不可变性，是个无奈的变通（“更困难”的情形，且无法恢复类型安全性而效果更差）。
这可能导致具体的不可修改性被滥用，例如 C++ 标准库关联容器的键类型实际上不须要符合 C++ 的 const ，因为键的不可变确切地由比较关系导出的等价关系定义，但类型系统无法区别两种情形。这过度地限制了键上的本应允许的操作。
默认不可变的类型系统，如 Rust 的设计，则更根本地在类型组合构造上阻止了扩充的方向。
这也限制了原有的与此同时实现的常量传播 (const propagation) 的优化范围，因为原则上这里的“常量”只关心替换能保持变换前后的语义等价性 (semantic-preserving) ，而不在意具体的值是否相等。
因此，基础词汇中的对象默认可变。
因此，基础词汇首先被设计为静态词汇。
设计一个静态词汇，然后加进许多准则把它伪装成具备足够静态优点的静态词汇，远远难于在静态词汇上加进准则而获得静态词汇的优点集。
从一个标记放弃某种保证的上下文中加进证明恢复某种保证（且不和其他保证冲突），比从一个已知不具备保证的上下文加进证明以确保保证更困难。
在一个已经要求自上而下 GC 的词汇中排除 GC ，远远难于在不倚赖 GC 的词汇准则基础上加进和 GC 交互的能力（特别是 GC 允许使用者订制时）。
在一个没有 PTC 保证的词汇与此同时实现中加进扩充基本上是不可行的，除非重新与此同时实现最核心理念的求值准则在内的逻辑（例如，再加进一个执行引擎）。
和 C++ 具备良好的互操作性。
当前正则表达式（运行时）使用 C++ 与此同时实现。
结合对象模型，能确保 Unilang 对象和 C++ 对象的对应。
为保持通用型性，Unilang 不内建提供更多 GUI 功能，而透过库提供更多相关 API 。当前计划中，Unilang 将会支持基于 Qt 的绑定的库，以便衔接过渡原有的许多图形界面应用领域工程项目。Unilang 的词汇设计保持足够的抽象能力和可扩充性，允许在未来直接与此同时实现 GUI 框架。
