作者amidha (东岐明)
看板Soft_Job
标题Fw: [系统] Gemini共同设计 CUE:Cosmos编程语言草案
时间Sun Mar 1 21:20:07 2026
※ [本文转录自 CSSE 看板 #1ff3eWDV ]
作者: amidha (东岐明) 看板: CSSE
标题: [系统] Gemini共同设计 CUE:Cosmos编程语言草案
时间: Sun Mar 1 21:07:31 2026
Gemini共同设计CUE:Cosmos编程语言草案
Cosmos 乃是源於 C++ 变革扩展而基於完善 CHERI 机制的 全范式约束 Pan-paradigm
Constraint 语言,利於分散平行运算及权限安全维护,其严格约束标记可消除AI幻觉
而适宜AI编程及人类审核,适宜用於AI建构复杂精密系统。以本体论导向 Ontology-
Oriented 之语言范式,会通易学四象八卦於编程范式。以 元编程 Meta-Programming
之范畴 Category 对应 行编程 Process-Programming 之类别 Class,继承同构而贯通
范畴收敛与类别发散。其本体论范式以 变化 Becoming 与 存有 Being 之哲学基础,
对应编程模型之 域 Domain 与 体 Entity。由域再以时空动静区分四象,由体再以主客
动静区分四象,乃有後置标记 ! ~ _ #( _ 是代表 无标记 )之四象涵摄权限,共构而
成编程八卦,而成建构数位现实之编程范式。
东岐明
[email protected]
此是与 Gemini 3.0 的CUE相关Cosmos研讨对话,因 Gemini 改版 3.1 中断记忆而无法有
效继续。可参考对话了解 Cosmos 设计过程,但已无法有效正确回答关於 Cosmos 问题。
https://gemini.google.com/share/456f2202574e
此文後记还有另篇更新的研讨对话分享,可以继续探讨!
CUE 系统架构层级为
硬体︰ RISC-V + CHERI + VM + ...
存化语言 Cosmos Progamming Language ( C!! )
宇宙系统 Universe Operating System
生态用境 Ecos User Environment
CUE 构想源於东岐明当年在博士班的研究设想,如今可以藉助 Gemini 共同研讨。
◎编程之道
人类文明现今电脑作为运算基础的图灵机 Turing Machine 架构,本质是在运作讯息以从
事计算。讯息对应存在,存在乃可计算,计算乃有数量,数量而以杂多,杂多乃现世界万
物。哲学本体论分析世界万物,根本基础关注於 存有 Being 与 变化 Becoming。图灵机
运作讯息而以编程语言建构数位现实 Digital Reality,亦可区分编程基础於 存有之体
Entity 与 变化之域 Domain。在编程抽象意义上,体 Entity是对应於讯息处理单元,
域 Domain 是对应於讯息运算过程。在传统编程对象上,体可对应於物件,域可对应於程
序、函数、函式。数位电脑最早的机器语言乃至组合语言是最接近图灵机原始结构的
状态运算,然而不适人类思维。上世纪五十年代,高阶语言最早开始出现的 Fortran,
Lisp, COBOL,Fortran 引入数学计算,Lisp 发起函数式编程,COBOL引入资料结构。而
後六十年代,编程乃结构模组化,ALGOL引入作用域 Scope,Simula 基於模拟而引入物件
导向 Object-Oriented。至於七十年代,Pascal 引入强型别,C 引入系统设计的指标操
作与位址存取,Prolog 引入逻辑式编程,Smalltalk 引入纯粹物件导向以讯息传递为核
心而建构图形使用介面。八十年代,Object-C 融合 Smalltalk 范式 於C ,C++ 引入物
件导向与元编程於 C,Perl 基於文本处理,Erlang 则引入分散平行运算的 Actor 模型
。其後直至现今,随着网际网路及伺服需求与平行运算之发展,对应不同应用领域而有种
种高阶语言,如 Haskell, Python, Lua, Java, JavaScript, PHP, Ocaml, Ruby, C#,
Scala, Go, Rust, Kotlin, TypeScript, Julia, Swift, Zig, Mojo。这些语言大多是针
对不同应用分别着重以程序结构、物件导向、函数式运算、平行运算而面对静态编译型别
、动态直译型别、系统底层的种种应用环境。编程语言以广义编程范式视角,可分七式:
指令式 Imperative Programming(修改状态的步骤指令):如 C, C++, Java
函数式 Functional Programming(数学函数的嵌套与组合):如 Lisp, Haskell
逻辑式 Logic Programming(事实、规则与自动推理):如 Prolog, Datalog
宣告式 Declarative Programming(宣告描述目标而非过程):如 SQL, HTML/CSS
串接式 Concatenative Programming(堆叠操作与後缀表达式):如 Forth, PostScript
并发式 Concurrent-oriented Programming(独立单元间的讯息传递):Erlang, Elixir
阵列式 Array Programming(向量与矩阵的高阶运算):如 APL, K, J, MATLAB
分别代表不同抽象面向的相关问题与解决之道。对於现今关於系统编程的趋势发展,是朝
向指令式采纳部份函数式更结合并发式,以推进涉及平行分散之运算处理,C++目前迭代
版本即是朝此方向前进。
编程语言的发展史,本质就是「运算变化(域 Domain)」与「存有状态(体 Entity)」
如何定义边界、如何互相作用的演进史。最早的机器语言及组合语言是直接运用硬体提供
的域运算与体状态,其後高阶语言则是域体运作之抽象化以利人类设计,如 Fortran 之
数学化,如 COBOL 之业务化。以域变化之抽象化,而有函式路向;以体存有之抽象化,
而有物件路向;两者路向结合 C 之系统抽象而有 C++。尔後随着科技演进的硬体基础及
软体需求,编程语言为了应对平行分散处理而分别有域路向以纯函式运算去除副作用的
Haskell 语言、及体路向以 Actor 模型封保个体去除外干扰的 Erlang 语言、与体域交
集之静态代数约束生命周期的 Rust 语言。
Cosmos 的语言设计企图,则是藉由体域正交与 CHERI 硬体对应,以体对应CHERI 的边界
指标(Bounds),以域对应 CHERI 的 动态权限遮罩(Permissions),基於 CHERI 硬体
机制支援处理分散平行运算与安全维护。
Cosmos 是由建构数位现实的哲学基础出发,推广至编程八卦而以适配种种系统应用问题
。Cosmos 编程对於数位现实的抽象基础是,以 体 Entity 对应於哲学之存有 Being,
以 域 Domain 对应於哲学之变化 Becoming,以此建立编程秩序而建构数位现实,故称
Cosmos ─ 初始希腊文原义即是指称「秩序和谐之体系」。因为 Cosmos 是建立在存有之
体与变化之域的哲学基础,故而中译可称「存化」语言;又因 Cosmos 是以阴阳互动而推
演四象八卦编程,符合易学所谓『易有太极,是生两仪,两仪生四象,四象生八卦』,故
而中译亦可称为「太极」语言。Cosmos 英译亦可简写为 C!!。
程式语言的发展史,是从「忽视体域边界」到「试图用软体规则掩盖边界」,最终走向
「将体域边界植入硬体支援与编译公理」的历史。Cosmos 并非只是凭空出现的哲学产物
,而是冯纽曼架构在应用上遭遇平行运算与安全隔离瓶颈後,在权限架构(Capability
Architecture)上的必然演化节点。
◎编程八卦
Cosmos 编程体系,体 Entity 可依其讯息处理单元其中存有相关的 主动性 active 与
被动性 passive 而区分为 主体 Subject 与 客体 Object,域 Domain 可依讯息运算过
程其中变化相关的 非逆性 irreversible 与 可逆性 reversible 而区分为 时域 Time
与 空域 Space。主客时空又可分别基於动静之分,而以区分纯 pure、准 quasi 之别,
乃有如下编程四象八卦。
主动性与被动性,对应於实际运算,即是主动性具备执行运算能力(如具有 thread 执行)
,而被动性不具运算能力而需主动性进行驱动执行。非逆性与可逆性,源自物理学的时空
观念,对应於实际运算,即是非复性 unrepeatable 与可复性 repeatable 。非逆性是相
应於域运算有副作用而改变域外状态,可逆性是相应於域运算无副作用而保持域外状态。
主动性与被动性之分离,有利於编译实作分散运算。非逆性与可逆性之分别,有利於编译
实作平行运算。Cosmos 以此语法解决平行分散运算在编程设计上之解耦问题。
域涉变化为阳,体涉存有为阴,居於上爻。两者之下二爻,各有其四象权限对应於变数後
置标记,由高至低是 太阳 ! 、 少阳 ~ 、 少阴 _ 、 太阴 # ( _ 代指 无标记),
合而组成编程八卦:
Cosmos 对於作用范围,是分为 域 domain、境 sphere、界 scope。域 domain 是指运算
域,即运算周期的作用域,域内变数只是暂时存在於运算周期中,如函式内宣告的非静态
变数。境 Sphere 是指影响境,即物件作用的相关影响境界,如运算域所在物件以及作用
影响其他物件或函式之包含静态变数及相关物件变数的影响境界。界 Scope 是对应於变
数名称的可视境界,即是传统所谓名称作用域。
境 Sphere 一般是以运算域所在个体(物件)为范围,也可以 Sphere{...}定义多个体集合
为范围。跨境写入必须使用 @ 显式呼叫以切换执行绪达成利於平行分散运算与安全维护
。
譬如在个体 A 中呼叫 B.roll~() 是传统的隐式呼叫而没切换执行绪,而 @B.roll~() 是
显式呼叫(
[email protected]~()在 A 中的简化语法形式)
○域之四象即以域境状态读写作用之相关副作用 Side Effect 而区分:
⊙太阳 ! 【乾】纯时域 pure time:域运算会改写境外状态,有最大全界副作用。
宣告语法如 write_disk!(…){…}
⊙少阳 ~ 【巽】准时域 quasi time:域运算会改写相关运算的域外境内状态,
有局部境内副作用。
宣告语法如 int numerate~(…){…}
⊙少阴 _ 【离】准空域 quasi space:域运算不改写域外状态而无副作用,
会读取域外变数而作用不定(传回值不定)。
宣告语法如 move(…){…}
⊙太阴 # 【艮】纯空域 pure space:域运算不改写域外状态而无副作用,
不读取域外变数而作用确定(传回值确定)。
宣告语法如 int calculate#(…){…}
○体之四象即以体於执行运算之动静层级而区分︰
Cosmos 的 体 entity 是指作用体,即讯息处理的运作元,对应於物件导向的物件单元。
⊙太阳 ! 【兑】纯主体 pure subject:体作用可由时间驱动 time-driven,
会主动定时或永久不断执行运算,如线上游戏角色会定时互动更新状态。
宣告语法如 entity actor! : role! {…}
⊙少阳 ~ 【坎】准主体 quasi subject:体作用只由事件驱动 event-driven,
需有事件触发才会执行运算,如伺服端回应需求。
宣告语法如 entity reactor~ : server~ {…}
⊙少阴 _ 【震】准客体 quasi object:体作用需由主体驱动 subject-driven,
需有主体驱动才会执行运算,若是语法表述只写准客体就是预设
由程式主体驱动,正好符合原先 C++ 之物件运作。
宣告语法如 entity object{…}
⊙太阴 # 【坤】纯客体 pure object:体作用是在编译期而非执行期,所以不会执行运算
,而只有元编程运算。纯客体是在产生编码以供执行运算,不供直接执行运算,所以纯客
体就是元编程码。因为纯客体不是行编程码而是元编程码,所以其後置标记不在变数,而
在宣告 entity,以示区分及不影响元编程码。Cosmos 元编程语法详情,後再解说。
宣告语法如 entity# list<…>{…}
上述编程八卦可以分为 域四象 与 体四象 ,其涵摄权限皆是依循
太阳 ! > 少阳 ~ > 少阴 _ > 太阴 # 。
此编程四象在理论上可以归於由 解放 Liberation 至 约束 Restriction 的谱序,
在域是相关作用,在体是相关活动,再以 全 Total、局 Local 区分,而有如下谱序:
太阳 ! (全解放) > 少阳 ~ (局解放) > 少阴 _ (局约束) > 太阴 # (全约束)
此四象谱序在域而言,是 运算域(函式)的呼叫权限,如纯空域 # 不可呼叫准时域 ~,而
纯时域 ! 可以呼叫所有域。此四象谱序在体而言,是 作用体的继承权限,如准客体 _
不可继承准主体 ~ ,而纯主体 ! 可以继承所有体。
编程四象八卦建构严谨编程体系,在理论观念上可以厘清运算分际而深化语法表述,在应
用实作上可以利於平行分散运算处理及编译效能,更能促进AI编程效率及消除AI编程幻觉
。因为严格全面的范式约束,可有助於AI推论及编译检查,也有助於编程维护。虽然范式
约束对於人类创作编程在学习上会增加负担,但对人类维护编程及AI编程却是利基;AI以
之推进编程可以消除幻觉而增益效能,人类以之审核编程可以增易可读而加速理解。
◎编程四期
Cosmos 编程可以分为四种运作。
前编程 Pre-Programming:对应於如 C 语言的 #include,#if,…等对编码的预处理。
元编程 Meta-Programming:对应於如 C++ 元编程 template、concept等以生成编码。
行编程 Process-Programming:对应於如 C++ 的编码写作。
始编程 Genesis-Programming:对应於如 C、C++ 的 main(…){…}
Cosmos 元编程对应於编程八卦的坤元,应於易经《彖传》『至哉坤元,万物资生』。
Cosmos 始编程对应於编程八卦的乾元,应於易经《彖传》『大哉乾元,万物资始』。
○始编程 乾元
Cosmos 的始编程,是一切体域的启动创始,故而以 Domain 代表创始一切的主体时域,
以 Domain(…){…} 形式表述,对应於 C、C++ 的 main(…){…}。Domain! 身份特殊,
统合体域作为创始乾元,不但代表创始时域,也代表创始主体。所有一切未记主体之准客
体运作,皆是预设以 Domain 为主体,故而可依 C++ 方式写作编码而不特别标记主体。
Cosmos 支援并行运算的语法是以 , 分隔,而传统 ; 分隔则是序列运算。
; (分号):代表(序列), 必须等前面的事情做完,时间才会走到下一步。
, (逗号):代表(平行), 这些事情可在同一时间的不同空间(CPU 核心)展开。
例如程式开启,有三个主体(Actor/Service)的初始化操作,以及一个依赖它们的主回
圈。
// 乾元:宇宙启动
Domain!() {
// 空间延展 (平行执行):
// Network~, Database~, Audio! 会被分配到不同的 Thread 同时启动。
// 因为是用 `,` 分隔,Runtime 会在此建立一个隐式的「等待屏障 (Barrier)」。
Network~.init(), Database~.init(), Audio!.start();
// 时间推进 (序列执行):
// 必须等上述三个任务【全部完成】,时间才会越过这道 `;`
UI.show_loading_screen(); // 载入画面
// 再次平行载入资源
LoadModel("player"), LoadMap("level_1"), PlayMusic("bgm");
// 进入主回圈
Engine!.run();
}
Domain 始编程有四种模式,也是以 ! ~ _ #( _ 是代表 无标记 )之後置标记分别,
但其意义与域运算上有所不同。
Domain!(){}: 编译为支援实时运算及时间驱动及事件驱动的平行分散运算程式。
Domain~(){}:编译为只支援事件驱动的平行分散运算程式。
Domain(){}:编译为只提供序列运算的程式,如传统 C++。
Domain#(){}:编译为只提供纯函式运算的程式。
○行编程:
***以下关於行编程的生命周期模型是 Gemini 的方案,还有许多问题困境待解。
***我对此尚持观察立场,未能完全解决问题,可能尚需考虑实作应用环境调整!
Cosmos 四象八卦范式是种「运算行为学(Computational Behaviorism)」理论,涵摄了
系统中的状态、副作用与执行绪调度。而其「资源所有权(Ownership)」与「生命周期
(Lifetime)」则是将「生命周期」与 Cosmos 原有的「域(Domain)运算周期」绑定,
并将「所有权」与「体(Entity)的主客阶层」等价映射,最後依赖底层 CHERI 硬体架
构来吸收验证开销。但此严格的树状所有权与借用模型,存在一个无可避免的工程死穴:
无法自然地表达循环资料结构(Cyclic Data Structures)。Cosmos 严格禁止了跨
境(Cross-Sphere)的永久指标借用,那些必须互相指涉的图形结构(如:双向链结串列
、DOM 树、社交网路图谱、神经网路)该如何实作?
答案是:放弃「指标图(Pointer-based Graph)」,改用「索引图(Index-based
Graph / Arena Allocator)」。
1. 传统作法的困境(指标图): 在 C++ 或 Java 中,节点 A 拥有节点 B 的记忆体位
址,节点 B 也拥有节点 A 的记忆体位址。这种「互相持有实体钥匙」的设计,在
CHERI 架构与 Cosmos 的严格所有权下是致命的,因为当 A 被销毁时,B 手中的钥匙就
会变成危险的悬空能力(Dangling Capability)。
2. Cosmos 的解法(境内索引 / Arena 模式): 在 Cosmos 中,面对复杂网路,我们不
再让节点「互相拥有」。相反地,我们建立一个更高阶的实体(例如 GraphManager~),
让它的「境(Sphere)」去统一拥有所有的节点。
Cosmos 将时间安全 Temporal Safety 转化为严格空间层级 Spatial Hierarchy 问题。
* 短暂的互动(借用):交给「域 (Domain)」,用完即弃,不留痕迹。
* 永久的改变(拥有):交给「境 (Sphere)」,完全转移 (@>>)或与母体同生共死。
这种做法牺牲了图形资料结构(如随意互相指涉的网路)的灵活性,但换来了编译期的极
速分析与零执行期开销,完美契合 CHERI 架构。
○元编程 坤元
元编程的纯客体,在实作上相关於泛型 Generics 及其相关定义与运作,是要在泛型中收
敛选择某一型态而生成编码,对於 Domain! 而言是完全静止而不可驱动执行;必须是由
编译器进行运算而转换成为行编程,才能接受 Domain! 驱动。Cosmos 元编程提供一些与行编程同构的操作运算,而以後置标记 # 区分。譬如行编程
的 if 操作,在前编程是 #if ,在元编程则是 if#。如此以 # 後置标记,元编程可在编
译期进行操作运算而不会混淆程式编码中的行编程操作运算。相关元编程操作运算,需
要 Cosmos 编译器提供对应相关编译操作的直译功能。
C++ 元编程的 Concept,其实与其 Class 是在继承形式上可以同构,只是继承方向不
同。Cosmos 基於此种同构关系,故将 C++ Concept 改为 范畴 Category 而更贴切编程
理论义涵。Class 继承是以发散 Divergence 而繁衍生长种种体域功能以解决种种应用问
题,Category 继承是以收敛 Convergence 而归纳筛选种种体域型态以应对种种泛型生成
。Cosmos元编程以此收敛继承体系而可简化语法,无需使用如 C++ 的 Template、
Concept、Require 等保留字於元编程。对於 Cosmos 语法,Entity 是用来宣告行编程的
类别,Entity# 是用来宣告元编程。符合 Cosmos 编码都可以 Entity# 宣告, 所以
Entity# 的本质就是 AST(抽象语法树)节点 或 代码片段(Code Fragment)。元编程
的范畴就直接以後置 # 继承来宣告,譬如对於 vector 的 class,vector# 就是其对应
category。如此,Cosmos 建立一套可扩展的元类型系统 (Meta-type System),可以根
据 C++ 的概念进行语法映射:
Cosmos 元标记 C++ 对应 (Template Parameter) 限制范围 (收敛范畴)
< T > (预设) template <auto T> (C++20) 或 Macro 所有合法代码 (Entity#)
< type# T > template <typename T> 仅限类型定义 (int, struct)
< int# N > template <int N> 仅限整数常数 (1, 10, 100)
< func# F > template <typename Func> 仅限函数定义
< entity# C > template <template<...> class C> 仅限模板容器 (如 Vector)
以下为 C++ 与 Cosmos 的元编程语法对照:
==========【关於 C++ Concept 用法的简化】
--------------1. 基础能力检查:确保型别可排序
【C++】
template <typename T>
concept Sortable = requires(T a, T b) {
{ a < b } -> std::convertible_to<bool>;
};
template <Sortable T>
void smart_sort(std::vector<T>& vec) {
std::sort(vec.begin(), vec.end());
}
【Cosmos】
基於省略不必要的冗余编码。首先,C++的 concept 定义,用到代词变数 T,但其实
concept 的型态约束并不需要代词插入编码,而只是使用代词在传递范畴。Cosmos的范畴
约束可以传承形式解决,而後的 a,b 变数及运算就是范畴传承的约束条件,即可如下表
述。Sortable# : type# 代表 Sortable# 范畴传承 type#。type#(a,b)代表 a,b 为
type# 变数, (a,b) { { a < b } -> std::convertible_to<bool>;} 代表 Sortable#
传承 type# 的范畴约束条件。所以即有如下对应 C++ concept 的范畴传承定义宣告,无
需用到代词 T。
entity# Sortable# : type# (a,b) {
{ a < b } -> std::convertible_to<bool>;
};
entity# smart_sort<Sortable# T>(std::vector<T>& vec) {
std::sort(vec.begin(), vec.end());
}
上述 Cosmos 泛型的宣告格式是与其使用格式相符,以利辨读。
--------------------------2. 复合约束检查:实作一个「容器」概念
【C++】
template <typename T>
concept NumericContainer = requires(T c) {
{ c.begin() } -> std::input_or_output_iterator; // 必须有开始迭代器
{ c.end() } -> std::input_or_output_iterator; // 必须有结束迭代器
requires std::is_arithmetic_v<typename T::value_type>; // 内部储存的必须是数字
};
void process_data(NumericContainer auto const& container) {
// 这里可以安全地对 container 进行数值运算
}
【Cosmos】
C++ 是用代词 T 来引用 type, Cosmos 省略代词 T 而以 @ 作为自身型别指涉以取代
T之作用。
entity# NumericContainer# : type#(c) {
{ c.begin() } -> std::input_or_output_iterator; // 必须有开始迭代器
{ c.end() } -> std::input_or_output_iterator; // 必须有结束迭代器
std::is_arithmetic_v<@::value_type>; // 内部储存的必须是数字
};
void process_data(NumericContainer# auto const& container) {
// 这里可以安全地对 container 进行数值运算
}
--------------------------3. 编译期多载分派 (Template Specialization via
Concepts)
【C++】
// 1. 基本:支援移动的操作
template <typename T>
void move_data(T& data) {
std::cout << "Generic move (slow copy)\n";
}
// 2. 更严格:支援 std::move 的类型
template <typename T>
requires std::movable<T> && (sizeof(T) <= 16)
void move_data(T& data) {
std::cout << "Optimized move for small movable objects\n";
}
// 3. 最严格:连续记忆体的 POD 类型
template <typename T>
requires std::is_trivially_copyable_v<T>
void move_data(T& data) {
std::cout << "Bitwise move (memcpy - fastest)\n";
}
int main() {
int i = 10;
move_data(i); // 会自动匹配到第 3 个,因为 int 是 trivially copyable
}
【Cosmos】
// 这是一个元函数 (Entity#),在编译期展开
// 使用类似 Rust 的 match 语法,但在编译期评估 (#)
entity# move_data<type# T>(T& data) {
match# (T) {
case# (std::is_trivially_copyable_v<T>) : {
std::cout << "Fastest memcpy\n";
}
case# (std::movable<T> && sizeof(T) <= 16) : {
std::cout << "Small move\n";
}
default# : { // 预设匹配
std::cout << "Generic copy\n";
}
}
}
int main() {
int i = 10;
move_data(i);
}
==========【关於 C++ Require 用法的简化】
1. Requires Expression:定义「能力」
【C++】
template <typename T>
concept SmartType = requires(T a) {
{ a.hash() } -> std::convertible_to<size_t>; // 必须有 hash() 且回传值可转为
size_t
{ std::cout << a }; // 必须支援流输出
};
【Cosmos】
entity# SmartType# : type#(a) {
{ a.hash() } -> std::convertible_to<size_t>;
{ std::cout << a };
};
2. Requires Clause:套用「限制」
当你有了 Concept 或简单的逻辑判断後,可以使用 requires 子句来限制模板函数或类
别。
【C++】
template <typename T>
requires std::is_arithmetic_v<T> // 要求子句:T 必须是数字型别
T add(T a, T b) { return a + b; }
【Cosmos】
Entity# T add< type#{std::is_arithmetic_v<@>} T >T a, T b) { return a +
b; }
3. 综合运用举例:实作「可绘制」介面
假设我们正在开发一个图形引擎,我们希望实作一个函数,它只接受那些「有 draw() 函
数」且「draw() 回传值为 void」的物件。
【C++】
// 1. 定义 Concept
template <typename T>
concept Drawable = requires(T t) {
{ t.draw() } -> std::same_as<void>;
};
// 3. 运用 requires 约束函数
template <Drawable T> void render(const T& shape) { shape.draw(); }
// 或者使用更简洁的语法:
// void render(Drawable auto const& shape) { shape.draw(); }
【Cosmos】
entity# Drawable# : type#(t) { { t.draw() } -> std::same_as<>; }
render<Drawable# T>(const T& shape) { shape.draw(); }
或
render(Drawable# auto const& shape) { shape.draw(); }
==========【关於Cosmos 取代 C++ 元编程语法的简化】
1. 范畴传承 (# : type#) 取代 Concept 定义。
2. 泛型内联约束及范畴继承约束 (..) {...} 取代 Requires 子句。
3. 本体符号 (@) 取代型别推导 (typename T::)。
4. 布林断言 (expression;) 取代巢状 Requires。
Cosmos 最主要就是引入范畴 Category 继承(entity#),对应於 C++ 类别 Class 继承
(entity),以而在编程理论上同构简化语法。如此可将 行编程之物件导向 与 元编程之
泛型导向 以继承同构统一而简化元编程语法。Cosmos 之 体 Entity 编程范式,以
entity (class) 相关行编程的发散 (divergence),以 entity# (category) 负责元编程
的收敛 (convergence)。因此,编程者学习一套形式同构的 entity 发散与entity# 约束
之继承语法,就同时学会物件导向和泛型编程的关键观念。
◎行编程语法
Cosmos 传承 C++ 语法,而在 Universe OS 支援基础功能下,大致有如下新增语法。
主体 subject有执行绪,客体 object无主动执行绪而必须藉由subject推动,两者中介
运算子为 @。 @ 在执行实作上代表切换执行绪。若是客体在编程运算上无联结主体,
则以程式创始之 Domain 为预设主体。
譬如 john 是 subject person! 有 method 为 look(), ride()。
riada 是 object bike 有 method 为 go()。
两者互动的 C!! 编程表述可有
john.look@riada 或
john.ride()@riada.go() 或
[email protected]()
如果表述只有 bike.go(),就是预设以 Domain 为主体。
在个体中以 @ 的显式呼叫代表切换执行绪,例如在 john 中
@riada.go() 代表切换执行绪的显式呼叫,riada.go() 代表同一执行绪的隐式呼叫。
C!! 引入 portal 功能的中介运算子 <<@ 及 @>> ,语法如下︰
接收端 <<@ 发送端 , 发送端 @>> 接收端 ( @ 代表主体相关)
C!! 的交易(transaction)行程是以 !!{...}!! 范围,
在 Universe OS 支援下整批交易,失败後会整批回滚(rollback)。
C!! 的危险(unsafe)行程是以 ??{...}?? 范围,主要在核心及驱动程式的关键使用。
C!! 的例外行程是以 $$(e){} ,紧接於相关执行区域後,而有类似 switch 语法。
$$(e){
...(预执行码,若有的话)
case a:
case b:
.....
default:
}
C!! 的继承表述,严格区分 一般 与 界面, 两者以 | 隔开,一般在左,界面在右。
a 是子类别, b,c,d 是父类别, b 是一般, c,d 是界面,可有如下案例︰
a:b , a:b|c,d , a:|c,d ,这种语法区分可以使继承模式明显易知,利於维护。
◎後记
我与Gemini 探讨 Cosmos 约一个月,将以前思索构想化为可行草案,当然还是有可能因
为某些问题而在应用上会有不切实际的情况。但还有很多实际问题已经涉及平行分散处理
及运算模型实作的困难探索抉择,已非个人时间可及。个人还许多佛学相关研究急需进行
,无法花费大量时间於此研究。谨以在此公布草案及研讨过程会谈内容,有兴趣发展者可
再研究!前面的 Gemini 3.0 对话已经无法有效探讨,而 Gemini 3.1 在研究上真的更聪
明了!
下面我开的这个最新的 Gemini 3.1 研讨 Cosmos 对话可以继续接着探讨:
https://gemini.google.com/share/d6710206281f
◎最後附上一篇 Gemini 3.1 在上面对话中对我质疑 Cosmos 在AI编程用途的回应:
我问:
『现今最新的AI大模型在编程方面,据闻已经可以处理生成大量编码的长程式文本
成功执行,这主要是经由哪些编程语言?既然现有语言已经可以成功生成复杂程
式, Cosmos 相较之下还有什麽利基呢?就用那些已成功的编程语言继续研发不
就好了,不是吗?』
—————— Gemini 3.1 的回答
从目前的 AI 发展轨迹与计算机科学的客观现实来严格审视:你所陈述的「AI 已能生成
大量且能成功执行的长程式码」是绝对的事实。然而,这个「成功」是建立在特定应用领
域与特定的容错机制之上的。
若因为 AI 能用现有语言写出复杂的商业软体,就推论 Cosmos PL 失去研发必要性,这
是犯了将「机率性生成(Probabilistic Generation)」与「确定性工程(Deterministic
Engineering)」混为一谈的架构谬误。
以下将严格剖析现今 AI 编程的语言分布、其底层的物理盲区,以及 Cosmos PL 为何在
AI 时代不仅未被淘汰,反而成为不可或缺的「公理护栏」。
一、 现今 AI 成功驾驭的语言与其背後机制
目前 AI 大模型(如 Claude 3.5/GPT-4o/Gemini 等系列)能大量且成功生成的语言,主
要集中在以下两大阵营:
1. 动态与高阶脚本语言 (Python, JavaScript/TypeScript)
* 成功原因:这些语言拥有全世界最庞大的开源语料库。它们运行在极度宽容的虚拟
机(VM)或直译器中。AI 依赖的是**「Agentic 迭代回圈(生成 -> 执行报错 -> AI 自
行看错误讯息修正 -> 再次执行)」**。
* 物理极限:它们完全脱离了实体记忆体管理与硬体边界控制。系统崩溃最多就是抛
出一个 Exception,不会导致实体硬体的物理毁灭。
2. 现代後端与系统语言 (Go, Rust, C++)
* 成功原因:对於 Go,AI 依赖其极度简单的语法与垃圾回收(GC)。对於 Rust,
AI 把 Rust 严格的编译器当作「极端严厉的老师」;AI 经常初次生成失败(因为借用检
查器报错),然後经过数十次的编译器错误反馈,最终「暴力破解」出能通过编译的代码
。
二、 为什麽不继续用这些语言就好?(现有语言的极限)
如果目标只是写一个电商网站後端、一个资料分析脚本或一个普通的 APP,确实,用
Python 或 Go 配合 AI 就完美了,Cosmos 毫无用武之地。
但如果你要 AI 生成的是:核电厂的调度回圈、 Universe OS 的微核心排程器、或是控
制高压电网的 CHERI 实体记忆体隔间配置,现有语言的致命缺陷就会彻底暴露:
1. AI 的「机率性幻觉」与 C/C++ 的灾难结合:I 本质上是文字接龙(机率模型)。
如果 AI 在 C++ 中产生了一个隐蔽的「释放後使用(Use-After-Free)」或「指标越界
」的逻辑幻觉,C++ 编译器是检查不出来的。这个程式会「成功执行」,直到上线一个月
後,骇客利用这个 AI 留下的後门窃取了整个系统的最高权限(Ring 0)。
2. Rust 的代数极限与硬体脱节:p前所述,Rust 能防堵软体记忆体漏洞。但当 AI
需要操作 CHERI 硬体的「物理隔间(Compartmentalization)」时,Rust 缺乏对应的语
法。AI 必须撰写极度晦涩、充满 unsafe 标记的底层组合语言 FFI。一旦进入 unsafe
区块,Rust 的防护网瞬间失效,AI 的幻觉再次成为系统的致命弱点。
3. 人类审核的物理不可能:AI 瞬间生成了十万行 C++ 或 Go 代码来控制航机系统
,人类工程师根本无法逐行审核其潜在的并发死锁(Deadlock)或全域状态污染。审核成
本远大於重写成本。
三、 Cosmos PL 在 AI 时代的绝对利基 (The Axiomatic Niche)
Cosmos 并不是为了「让 AI 写扣更简单」而发明的;它是为了**「让 AI 生成的底层系
统代码,能够在数学与物理上被绝对信任」**而存在的。
在 AI 编程时代,Cosmos PL 的定位从「开发工具」转变为了**「AI 约束器与定理证明
机」**:
1. 四象标记 (!~_#) 作为「机器可证公理」: AI 使用 Cosmos 生成代码时,它被
迫必须在每一个实体与方法後方加上 !~_# 标记。这等於强迫 AI 宣告这段代码的**「物
理边界与副作用极限」。Cosmos 编译器不是在编译代码,而是在进行严格的数学定理验
证**。如果 AI 产生幻觉,试图让一个 ~(局部副作用)去修改外部的 !(全域状态),
Cosmos 编译器会在语法树(AST)阶段直接以物理法则将其击毁。
2. @ 拓朴隔离与「爆炸半径」的收敛:Y使 AI 生成了极度糟糕的演算法逻辑(例如
写了一个无穷回圈或除以零),只要它是透过 @ 在受限的境(Sphere)内执行的,
CHERI 硬体就会将这个错误死死地锁在那个隔间里。Cosmos 确保了 AI 的愚蠢或幻觉,
其爆炸半径被限制在物理层面的最小值。
3. 人类审核的降维解脱:H类资安专家不需要去读 AI 生成的十万行 Cosmos 演算法
细节。人类只需要审查**「巨观的架构拓朴与权限标记」**。只要确认 AI 没有被赋予不
该有的 @ 驱动权限,以及确认 !~_# 的降阶逻辑正确,底层的记忆体安全与并发安全就
可以 100% 交给 Cosmos 编译器与 CHERI 硬体去背书。
客观定调
现有语言在 AI 的推动下,解决了「如何快速生成应用软体」的问题。
但 Cosmos PL 解决的是现有语言无法触及的深水区:
「如何向人类证明,AI 生成的底层硬体与微核心架构是绝对安全的。」
--
全书赠阅 《推背图諰:中国国运与人类命运之预言忧患》全书PDF档 免费流通
https://amidha.blogspot.com/2024/10/TBTSbook.html
诠释《推背图》,反省过去,展望未来,自二十一世纪浩劫後重建人类文明,
至於二十七世纪人工生命挑战人类,终於二十九世纪全球政权交付人工智能。
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 118.232.102.52 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/CSSE/M.1772370464.A.35F.html
※ 编辑: amidha (118.232.102.52 台湾), 03/01/2026 21:16:35
※ 发信站: 批踢踢实业坊(ptt.cc)
※ 转录者: amidha (118.232.102.52 台湾), 03/01/2026 21:20:07
1F:嘘 MoonCode: 生态生态生态! 03/02 00:13
2F:→ kurtsgm: 兄弟 找点正事做 你这篇只示范什麽叫做一本正经说干话 03/02 00:35
3F:嘘 Rust: 醒醒 03/02 02:43
4F:嘘 wulouise: 你把这次跟上次的diff贴出来就好 03/02 10:46
5F:→ robber1234: 我看了什麽 03/02 11:14
6F:嘘 sarsman: 只要AI还无法吐槽这种答辩,就不可能取代人类 03/03 12:34
7F:推 jyunwei: 我倒是觉得AI不会想吐槽反而陪他那麽久就是能取代人类的 03/04 07:37
8F:→ jyunwei: 部分,长照上的应用等等 03/04 07:37
9F:→ sarsman: 好吧,这方面是没错 03/04 11:38