Fw: [系統] Gemini共同設計 CUE：Cosmos編程語言草案
※ [本文轉錄自 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。由域再以時空動靜區分四象，由體再以主客
動靜區分四象，乃有後置標記 ! ~ _ #（ _ 是代表 無標記 ）之四象涵攝權限，共構而
成編程八卦，而成建構數位現實之編程範式。
東岐明
amidha.orienta@gmail.com
此是與 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~() 是
顯式呼叫（ A@B.roll~()在 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() 或
john@riada.go()
如果表述只有 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://www.ptt.cc/bbs/CSSE/M.1772370464.A.35F.html
※ 編輯: amidha (118.232.102.52 臺灣), 03/01/2026 21:16:35
※ amidha:轉錄至看板 Soft_Job 03/01 21:20
※ 發信站: 批踢踢實業坊(ptt.cc)
※ 轉錄者: amidha (118.232.102.52 臺灣), 03/01/2026 21:20:19
Tech_Job 近期熱門文章
PTT職涯區 即時熱門文章