# 共通程式底空間：跨語言語義正規化與表徵收斂

**Common Program Base Space: Cross-Language Semantic Normalization and Representational Convergence**

**系列：** 程式底空間與本體反演系列（Program Base Space and Ontology Inversion, PBSOI）  
**篇次：** Paper 04  
**版本：** v0.1  
**作者：** Neo.K  
**機構：** EveMissLab  
**日期：** 2026-09-14  
**狀態：** 跨語言理論初稿／正規化框架定義

**公司：** 一言諾科技有限公司  

---

## 摘要

前述 PBSOI 系列已分別建立「程式底空間」、「程式碼誘導語義圖」與「程式本體反演」。在此基礎上，本文進一步研究一個更具挑戰性的問題：若不同程式語言可以實現相同或近似相同的計算功能，則它們經本體反演後，是否存在一個可比較、可正規化、可部分共享的共同程式底空間？

本文提出「共通程式底空間」（Common Program Base Space, CPBS），將其定義為：不同程式語言在去除純表面語法差異後，仍可被共同承載、比較與變換的計算關係子空間。本文特別反對一個過度簡化的主張，即「所有程式語言最終都等同於同一種底層機器碼，因此必然存在完整共同本體」。語言之間除了表面語法不同，也可能在型別、記憶體、所有權、生命週期、錯誤處理、並行、未定義行為、效果與控制模型上具有不可消除的語義差異。

因此，本文將語言特定底空間寫為：

$$
B_L
=
B_{\mathrm{common}}
\oplus
B_L^{\mathrm{specific}}
$$

其中 $B_{\mathrm{common}}$ 是跨語言可共享部分， $B_L^{\mathrm{specific}}$ 則保存語言不可被安全抹除的專有語義。本文提出跨語言正規化映射 $N_L$ 、語義收斂關係、共享不變量、語言特定殘差與正規化損失，並區分「語法收斂」、「結構收斂」、「行為收斂」、「效果收斂」與「契約收斂」。

本文進一步提出：共通底空間不應被理解為唯一且固定的宇宙語言，而應被理解為依任務、分析解析度與可接受等價條件而形成的共享結構域。對某些任務，控制流與資料流即可形成足夠共同空間；對其他任務，ownership、exception、concurrency 或 memory model 必須被保留為不可約語義。

本文最後建立跨語言收斂的實驗框架與可證偽條件。若不同語言對同一明確功能的實現，在保留必要語義後仍無法形成穩定共享結構，則 CPBS 的強版本必須被否定。若收斂只在極度粗粒化後才成立，則 CPBS 應被視為任務相對的局部共同域，而非完整程式本體的共同基底。

本文的核心命題是：

> **不同程式語言不必共享完整本體，但可能共享可由反演與正規化恢復的計算關係核心；真正的研究問題不是「語言是否相同」，而是「哪些語義可以安全收斂，哪些差異必須保留」。**

---

## 關鍵詞

共通程式底空間、Common Program Base Space、CPBS、跨語言語義、語義正規化、表徵收斂、程式本體反演、CISG、跨語言轉譯、程式等價、語言特定語義、語義殘差

---

# 一、問題的提出

## 1.1 相同功能，不同語言

考慮兩個函式。

Python：

```python
def f(x):
    if x > 10:
        return x * 2
    return x + 3
```

Rust：

```rust
fn f(x: i32) -> i32 {
    if x > 10 {
        x * 2
    } else {
        x + 3
    }
}
```

兩者表面不同：

- 語法不同；
- 型別標示不同；
- return style 不同；
- block 表達不同。

但其核心計算關係似乎高度相似：

$$
x
\rightarrow
(x>10)
\rightarrow
\operatorname{Branch}
$$

然後：

$$
x
\rightarrow
2
\rightarrow
\operatorname{Mul}
$$

或：

$$
x
\rightarrow
3
\rightarrow
\operatorname{Add}
$$

如果本體反演能將兩者轉為：

$$
G_{\mathrm{py}}
$$

與：

$$
G_{\mathrm{rs}}
$$

則自然出現問題：

$$
N_{\mathrm{py}}(G_{\mathrm{py}})
\stackrel{?}{\approx}
N_{\mathrm{rs}}(G_{\mathrm{rs}})
$$

其中：

$$
N_L
$$

是語言特定正規化映射。

---

## 1.2 「都會編譯成機器碼」不是答案

一個常見回答是：

> 所有高階語言最後都會編譯成機器指令，所以當然有共同底層。

這個說法只回答了執行載體的一部分。

例如：

- Rust ownership；
- C undefined behavior；
- Python dynamic object model；
- Java exception semantics；
- Haskell laziness；
- JavaScript prototype chain；
- async event loop；
- actor model；

不會因為最終都在 CPU 上執行，就自動失去語義差異。

因此：

$$
\text{Shared Hardware}
\not\Rightarrow
\text{Shared Program Ontology}
$$

同樣：

$$
\text{Same Output}
\not\Rightarrow
\text{Same Semantics}
$$

所以共通程式底空間不能被定義成：

$$
B_{\mathrm{common}}
=
\text{Machine Instructions}
$$

---

# 二、共通程式底空間的定義

## 2.1 語言特定底空間

對語言 $L$，定義：

$$
B_L
$$

表示該語言可合法表達與執行的程式關係空間。

其中包含：

- 控制結構；
- 資料關係；
- 型別；
- 狀態；
- 記憶體；
- 效果；
- 錯誤；
- 並行；
- 語言特定約束。

---

## 2.2 共通底空間

給定語言集合：

$$
\mathcal L
=
\{L_1,L_2,\ldots,L_n\}
$$

本文定義候選共通底空間：

$$
B_{\mathrm{common}}^{\mathcal L,\mathcal C}
$$

其中：

$$
\mathcal C
$$

表示分析語境或等價條件。

換句話說，共通底空間不是無條件唯一。

它依賴：

- 比較什麼功能；
- 保留什麼語義；
- 忽略什麼表面差異；
- 要求何種等價。

因此：

$$
B_{\mathrm{common}}
=
B_{\mathrm{common}}(\mathcal L,\mathcal C)
$$

---

## 2.3 語言特定殘差

對每個語言：

$$
B_L
=
B_{\mathrm{common}}
\oplus
B_L^{\mathrm{specific}}
$$

其中：

$$
B_L^{\mathrm{specific}}
$$

表示不能安全正規化掉的語義殘差。

例如 Rust 中：

$$
B_{\mathrm{Rust}}^{\mathrm{specific}}
$$

可能包含：

- ownership；
- borrowing；
- lifetime；
- move semantics。

而 C 中可能包含：

- raw pointer semantics；
- undefined behavior conditions；
- manual lifetime；
- implementation-defined behavior。

因此：

$$
B_{L_1}^{\mathrm{specific}}
\neq
B_{L_2}^{\mathrm{specific}}
$$

是正常的。

---

# 三、跨語言正規化

## 3.1 正規化映射

對語言 $L$：

$$
N_L
:
G_L
\rightarrow
\widetilde{G}_L
$$

其中：

- $G_L$：由語言 $L$ 的程式反演所得 CISG；
- $\widetilde{G}_L$：去除部分語言表面差異後的正規圖。

例如：

Python：

```text
hashlib.sha256(x).hexdigest()
```

Rust：

```text
format!("{:x}", Sha256::digest(x))
```

在某個適當抽象層下，可能都被正規化為：

$$
\operatorname{SHA256}
\rightarrow
\operatorname{HEX}
$$

---

## 3.2 正規化不是刪除所有差異

若正規化為了得到漂亮的一致結果而抹除真正重要的語義，就失去意義。

因此正規化必須滿足：

$$
\operatorname{Preserve}_{\mathcal C}(N_L)
$$

也就是在語境 $\mathcal C$ 下保留指定不變量。

例如若 $\mathcal C$ 是：

> 比較純函式數值結果。

則 ownership 可能不是必要保留項。

但若 $\mathcal C$ 是：

> 比較 memory safety 與資源生命週期。

則 ownership 絕不能被抹除。

---

# 四、五種收斂層級

本文區分至少五種跨語言收斂。

## 4.1 語法收斂

$$
C_{L_1}
\sim_{\mathrm{syntax}}
C_{L_2}
$$

這通常價值最低。

不同語言甚至沒有必要在語法上相似。

---

## 4.2 結構收斂

$$
N_{L_1}(G_{L_1})
\sim_{\mathrm{struct}}
N_{L_2}(G_{L_2})
$$

例如共享：

- branch；
- call；
- dependency；
- data flow；
- state transition。

---

## 4.3 行為收斂

對輸入域：

$$
X
$$

若：

$$
\forall x\in X,
\quad
E_{L_1}(x)
=
E_{L_2}(x)
$$

則在該輸入域下行為等價。

但這仍不表示內部語義完全一致。

---

## 4.4 效果收斂

若兩程式對外界造成相同效果：

$$
F_{L_1}
\sim
F_{L_2}
$$

例如：

- 相同檔案寫入；
- 相同 network request；
- 相同 database mutation。

則可以稱 effect-level convergence。

---

## 4.5 契約收斂

若：

$$
K_{L_1}
\sim
K_{L_2}
$$

表示：

- 相同前置條件；
- 相同後置條件；
- 相同 error boundary；
- 相同可接受輸入／輸出。

則為 contract convergence。

---

# 五、跨語言語義核

## 5.1 核心運算集合

本文定義候選共享操作集合：

$$
\Omega_{\mathrm{common}}
$$

可能包含：

- constant；
- input；
- arithmetic；
- comparison；
- branch；
- merge；
- call；
- return；
- load；
- store；
- allocate；
- transform；
- validate；
- emit effect。

此集合不必一次完整。

更合理的是：

$$
\Omega_{\mathrm{common}}^{(0)}
\subset
\Omega_{\mathrm{common}}^{(1)}
\subset
\cdots
$$

逐步擴張。

---

## 5.2 語言到核的映射

對每個語言：

$$
\eta_L
:
\Omega_L
\rightarrow
\Omega_{\mathrm{common}}
\cup
\Omega_L^{\mathrm{specific}}
$$

如果某操作無法安全映射：

$$
\eta_L(o)
\in
\Omega_L^{\mathrm{specific}}
$$

而不是強迫：

$$
\eta_L(o)
\in
\Omega_{\mathrm{common}}
$$

---

# 六、語義殘差

## 6.1 定義

正規化後仍無法消除的語言特定部分稱為：

$$
R_L
$$

即 semantic residual。

可以寫成：

$$
R_L
=
G_L
-
\operatorname{Lift}_{L}
(
N_L(G_L)
)
$$

此式表示概念差，不要求實作一定採集合減法。

---

## 6.2 殘差不是噪音

例如 Rust 的 lifetime：

$$
R_{\mathrm{Rust}}
$$

不應因 Python 沒有顯式對應物而被視為：

> 多餘語法。

它可能是：

$$
\text{Safety Semantics}
$$

的一部分。

因此：

$$
\boxed{
\text{Language-Specific}
\neq
\text{Unimportant}
}
$$

---

# 七、正規化損失

## 7.1 定義

任何正規化都可能損失資訊。

定義：

$$
\mathcal L_N
=
(
\ell_{\mathrm{control}},
\ell_{\mathrm{data}},
\ell_{\mathrm{state}},
\ell_{\mathrm{effect}},
\ell_{\mathrm{type}},
\ell_{\mathrm{memory}},
\ell_{\mathrm{error}},
\ell_{\mathrm{concurrency}}
)
$$

表示各語義維度的損失。

---

## 7.2 任務相對損失

對任務：

$$
\mathcal T
$$

定義權重：

$$
w_{\mathcal T}
$$

則：

$$
\mathcal L_N^{\mathcal T}
=
w_{\mathcal T}
\cdot
\mathcal L_N
$$

例如做純數值等價時：

$$
w_{\mathrm{memory}}
$$

可以較低。

但做安全性分析時：

$$
w_{\mathrm{memory}}
$$

與：

$$
w_{\mathrm{type}}
$$

必須提高。

---

# 八、共通底空間不是單一固定層

## 8.1 多解析度共同域

可以定義：

$$
B_{\mathrm{common}}^{(R_0)}
$$

到：

$$
B_{\mathrm{common}}^{(R_n)}
$$

其中：

- $R_0$：粗粒功能；
- $R_1$：module / call；
- $R_2$：control / data；
- $R_3$：state / effects；
- $R_4$：memory / concurrency / language semantics。

隨解析度提高：

$$
|B_{\mathrm{common}}^{(R_{k+1})}|
\leq
|B_{\mathrm{common}}^{(R_k)}|
$$

通常成立。

原因是解析度越細，語言差異越容易顯現。

---

## 8.2 粗粒化容易造成假收斂

若只比較：

> 輸入一個數，輸出另一個數。

那幾乎所有實現都可以被視為相同。

但這種收斂可能只是：

$$
\text{Over-Coarse Projection}
$$

因此必須避免：

$$
\text{Similarity by Information Destruction}
$$

也就是透過刪除太多資訊來製造假共同域。

---

# 九、跨語言等價關係

## 9.1 語境化等價

定義：

$$
P_1
\equiv_{\mathcal C}
P_2
$$

表示在語境 $\mathcal C$ 下兩程式等價。

不同 $\mathcal C$ 可能要求：

- output equivalence；
- state equivalence；
- effect equivalence；
- temporal equivalence；
- contract equivalence；
- safety equivalence。

---

## 9.2 等價不是同一

即使：

$$
P_1
\equiv_{\mathcal C}
P_2
$$

也不代表：

$$
P_1=P_2
$$

例如：

$$
O(n)
$$

與：

$$
O(n^2)
$$

的兩個程式可能在有限測試集下輸出相同，但性能本體不同。

因此可以保存：

$$
\Delta_{\mathrm{residual}}
$$

表示：

> 在選定等價語境之外仍存在的差異。

---

# 十、跨語言收斂圖

## 10.1 Pairwise convergence

對：

$$
G_i,
G_j
$$

定義：

$$
C_{ij}
=
\operatorname{CommonSubstructure}
(
N_i(G_i),
N_j(G_j)
)
$$

---

## 10.2 多語言交集

對：

$$
\mathcal G
=
\{G_1,\ldots,G_n\}
$$

可定義：

$$
C^\ast
=
\bigcap_{i=1}^{n}
N_i(G_i)
$$

概念上表示跨全部語言都保存的共同結構。

但實際上：

$$
C^\ast
$$

可能隨 $n$ 增大迅速縮小。

因此，也可研究：

$$
C_\alpha
$$

表示至少被比例 $\alpha$ 語言支持的共同 motif。

---

# 十一、Common Motif Library

## 11.1 從程式語言轉向程式功能形狀

若不同語言中 repeatedly 出現：

$$
M_k
$$

則可以建立：

$$
\mathcal M_{\mathrm{common}}
=
\{
M_1,M_2,\ldots,M_m
\}
$$

其中可能包括：

- parse-validate-transform；
- lookup-cache-fallback；
- authenticate-authorize；
- acquire-use-release；
- retry-backoff-fail；
- read-modify-write。

---

## 11.2 Motif 不是自然語言標籤

例如：

$$
M_{\mathrm{auth}}
$$

首先應由結構定義：

$$
M_{\mathrm{auth}}
=
(
V_M,
E_M,
K_M
)
$$

之後才附加：

$$
\operatorname{Name}(M)
=
\text{"authentication"}
$$

因此：

$$
\text{Label}
\neq
\text{Motif Identity}
$$

---

# 十二、語言投影與再生成

## 12.1 正向投影

若共通圖：

$$
G^\ast
$$

具有足夠語義，可以定義：

$$
\pi_L
:
G^\ast
\rightarrow
C_L
$$

---

## 12.2 轉譯

跨語言程式轉譯因此可以寫成：

$$
C_A
\xrightarrow{\rho_A}
G_A
\xrightarrow{N_A}
G^\ast
\xrightarrow{\pi_B}
C_B
$$

這比：

$$
C_A
\rightarrow
C_B
$$

直接文字到文字轉譯多出一個可檢查中介層。

---

## 12.3 無法投影時應拒絕

若：

$$
G^\ast
$$

包含語言 $B$ 無法忠實表示的語義：

$$
\exists x\in G^\ast,
\quad
\pi_B(x)
\text{ undefined}
$$

則系統應：

- 顯式失敗；
- 要求語義降級；
- 引入 runtime support；
- 或保留 residual。

不應靜默改變程式語義。

---

# 十三、跨語言收斂的實驗設計

## 13.1 最小實驗

選定功能：

$$
F
$$

用：

- Python；
- Rust；
- JavaScript；
- C；

各實現一次。

得到：

$$
C_{\mathrm{py}},
C_{\mathrm{rs}},
C_{\mathrm{js}},
C_{\mathrm{c}}
$$

---

## 13.2 反演

分別：

$$
\rho_{\mathrm{py}}
(C_{\mathrm{py}})
\rightarrow
G_{\mathrm{py}}
$$

$$
\rho_{\mathrm{rs}}
(C_{\mathrm{rs}})
\rightarrow
G_{\mathrm{rs}}
$$

$$
\rho_{\mathrm{js}}
(C_{\mathrm{js}})
\rightarrow
G_{\mathrm{js}}
$$

$$
\rho_{\mathrm{c}}
(C_{\mathrm{c}})
\rightarrow
G_{\mathrm{c}}
$$

---

## 13.3 正規化

再執行：

$$
N_L(G_L)
$$

比較：

- node type overlap；
- edge type overlap；
- control topology；
- data-flow structure；
- state transition；
- effect boundary；
- contract。

---

## 13.4 行為驗證

給定測試集合：

$$
X_T
$$

驗證：

$$
\forall x\in X_T,
\quad
E_i(x)
=
E_j(x)
$$

同時不能把：

$$
X_T
$$

當成完整形式證明。

---

# 十四、收斂指標

## 14.1 結構重合率

概念上：

$$
S_{\mathrm{struct}}
=
\frac{
|M(G_i,G_j)|
}{
|U(G_i,G_j)|
}
$$

其中：

- $M$：匹配結構；
- $U$：比較範圍中的 union。

---

## 14.2 語義殘差率

$$
S_{\mathrm{residual}}
=
\frac{
|R_i|+|R_j|
}{
|G_i|+|G_j|
}
$$

---

## 14.3 效果收斂

$$
S_{\mathrm{effect}}
=
1-
d(
F_i,
F_j
)
$$

---

## 14.4 契約收斂

$$
S_{\mathrm{contract}}
=
1-
d(
K_i,
K_j
)
$$

---

## 14.5 不使用單一總分

本文不建議：

$$
S_{\mathrm{all}}
=
0.87
$$

作為唯一結果。

更合理的是：

$$
S
=
(
S_{\mathrm{struct}},
S_{\mathrm{behavior}},
S_{\mathrm{state}},
S_{\mathrm{effect}},
S_{\mathrm{contract}},
S_{\mathrm{residual}}
)
$$

---

# 十五、幾類不可安全收斂的語義

## 15.1 Ownership

Rust：

$$
\text{move}
$$

與 Python object reference 不應在 memory-safety 語境下被視為相同。

---

## 15.2 Undefined Behavior

C 中：

$$
\text{UB}
$$

不能直接被正規化成：

$$
\text{ordinary error}
$$

因為其語義地位不同。

---

## 15.3 Lazy Evaluation

惰性求值與嚴格求值在：

- termination；
- memory；
- side effect order；

上都可能不同。

---

## 15.4 Exception / Result

語言 A：

$$
\operatorname{throw}
$$

與語言 B：

$$
\operatorname{Result<T,E>}
$$

在粗粒錯誤傳遞上可能相似，但在控制、型別與 effect 上不完全一致。

---

## 15.5 Concurrency Model

thread、async/await、actor、CSP、event loop：

$$
\text{都能並行}
$$

不等於：

$$
\text{具有相同並行本體}
$$

---

# 十六、共通底空間與 IR

## 16.1 與 Universal IR 的差異

CPBS 不等同於：

> 再設計一個可以編譯所有語言的 universal IR。

Universal IR 通常優先關心：

- lowering；
- optimization；
- code generation。

CPBS 則關心：

- 什麼語義可共享；
- 什麼語義不可約；
- 反演結果如何比較；
- 正規化造成多少損失；
- 如何保存 provenance 與 uncertainty。

---

## 16.2 IR 可以是 CPBS 的實作方式之一

若某 IR 已經足夠表達：

$$
B_{\mathrm{common}}
$$

則完全可以直接採用。

因此：

$$
\boxed{
\text{CPBS 是研究問題，不要求重新發明所有 IR。}
}
$$

---

# 十七、與程式底空間與本體反演的關係

Paper 01：

$$
B_{\mathrm{prog}}
$$

回答：

> 程式關係存在於什麼承載域？

Paper 02：

$$
G_C
$$

回答：

> 實際程式目前形成了什麼證據圖？

Paper 03：

$$
\rho_L
$$

回答：

> 如何從語言投影恢復可觀測本體？

本文則研究：

$$
N_L
$$

以及：

$$
B_{\mathrm{common}}
$$

回答：

> 不同語言反演後，哪些部分可以真正對齊？

所以整條鏈變成：

$$
C_L
\xrightarrow{\rho_L}
G_L
\xrightarrow{N_L}
B_{\mathrm{common}}
\oplus
B_L^{\mathrm{specific}}
$$

---

# 十八、可證偽條件

## 18.1 無穩定共享結構

若功能明確等價的多語言實現，在保留必要語義後：

$$
N_i(G_i)
$$

之間沒有可重現的共享結構，則：

$$
B_{\mathrm{common}}
$$

的強版本應被否定。

---

## 18.2 只有粗粒化後才相同

若必須把程式壓縮成：

> input → output

才得到相同結果，則：

$$
B_{\mathrm{common}}
$$

只具有極弱意義。

---

## 18.3 語言特定殘差過大

若：

$$
|B_L^{\mathrm{specific}}|
\gg
|B_{\mathrm{common}}|
$$

對多數現實程式皆成立，則 CPBS 的適用範圍應被縮限。

---

## 18.4 正規化不可重現

若：

$$
N_L
$$

在相同 source 與 analyzer config 下無法穩定產生相同 canonical graph，則跨語言比較缺乏可信基礎。

---

## 18.5 正規化破壞重要語義

若系統為提高 convergence score 而持續刪除：

- memory；
- effects；
- safety；
- errors；
- timing；

等必要資訊，則得到的是假收斂。

---

# 十九、核心命題

本文提出以下八個核心命題。

## 命題 1：部分共通命題

不同語言可能存在：

$$
B_{\mathrm{common}}
$$

但不要求：

$$
B_{L_1}=B_{L_2}
$$

---

## 命題 2：語言殘差命題

$$
B_L
=
B_{\mathrm{common}}
\oplus
B_L^{\mathrm{specific}}
$$

語言特定語義是正式結構，不是噪音。

---

## 命題 3：正規化保真命題

任何：

$$
N_L
$$

都必須聲明其保留的不變量。

---

## 命題 4：任務相對命題

$$
B_{\mathrm{common}}
=
B_{\mathrm{common}}(\mathcal L,\mathcal C)
$$

共通底空間依賴語言集合與分析語境。

---

## 命題 5：多層收斂命題

跨語言相似性至少應區分：

$$
\text{structure}
,
\text{behavior}
,
\text{state}
,
\text{effect}
,
\text{contract}
$$

---

## 命題 6：殘差保存命題

不可安全收斂的語義應進入：

$$
B_L^{\mathrm{specific}}
$$

而不是被刪除。

---

## 命題 7：中介轉譯命題

跨語言轉譯可表示為：

$$
C_A
\rightarrow
G^\ast
\rightarrow
C_B
$$

並使語義差分顯式可檢查。

---

## 命題 8：假收斂禁止命題

$$
\text{Information Loss}
\not\Rightarrow
\text{Semantic Equivalence}
$$

不能透過過度粗粒化製造「所有語言都一樣」的結論。

---

# 二十、後續工程路線

下一階段應建立一個受限但嚴格的 cross-language benchmark。

第一組功能應避免 framework noise，選擇：

1. arithmetic + branch；
2. parse + validate；
3. collection transform；
4. state update；
5. error propagation；
6. resource acquire / release。

對每組各實現：

- Python；
- Rust；
- C；
- JavaScript。

之後：

$$
\text{Source}
\rightarrow
\text{CISG}
\rightarrow
\text{Normalization}
\rightarrow
\text{Convergence Report}
$$

並輸出：

$$
S
=
(
S_{\mathrm{struct}},
S_{\mathrm{behavior}},
S_{\mathrm{state}},
S_{\mathrm{effect}},
S_{\mathrm{contract}},
S_{\mathrm{residual}}
)
$$

這將成為 CPBS 的第一組直接實驗。

---

# 二十一、與下一篇的關係

Paper 05 將研究：

$$
G
\rightarrow
E(G)
$$

即：

> 若跨語言反演與正規化得到的圖已保存足夠語義，它是否可以不再依附原始碼而直接執行？

這將把：

$$
B_{\mathrm{common}}
$$

從純分析層推向執行層。

若成立，則：

$$
\text{Programming Language}
$$

將更接近：

$$
\text{Program Semantic Structure 的投影／編輯界面}
$$

而非唯一 canonical source。

---

# 二十二、結論

本文提出「共通程式底空間」CPBS，研究不同程式語言經本體反演後是否存在可共享的計算關係核心。

本文拒絕兩種極端。

第一種極端：

> 所有語言都不同，因此不存在任何共同語義。

第二種極端：

> 所有語言最後都跑在 CPU 上，因此完全等價。

更合理的模型是：

$$
\boxed{
B_L
=
B_{\mathrm{common}}
\oplus
B_L^{\mathrm{specific}}
}
$$

其中：

$$
B_{\mathrm{common}}
$$

承載可跨語言比較與轉譯的共享計算結構，而：

$$
B_L^{\mathrm{specific}}
$$

保存 ownership、memory、error、concurrency、type 與其他不可安全抹除的語言特定語義。

因此，跨語言研究的真正問題不再只是：

> Python 如何翻成 Rust？

而是：

> **Python 與 Rust 的程式實作中，哪些計算關係其實屬於共同底空間，哪些語義只能存在於各自的語言特定殘差，而任何轉譯都必須明確處理這些差異？**

這使跨語言轉換可以由：

$$
\text{Text-to-Text Translation}
$$

提升為：

$$
\boxed{
\text{Ontology Reconstruction}
\rightarrow
\text{Semantic Normalization}
\rightarrow
\text{Verified Reprojection}
}
$$

也使「共通域底空間」不再只是一個直覺，而成為可以透過跨語言實驗直接被驗證、限制或否定的研究命題。

---

# 參考與前置理論

1. Neo.K，《程式底空間：從原始碼表徵到計算關係的存在層》，PBSOI Paper 01。
2. Neo.K，《程式碼誘導語義圖：由實作生成而非由設計繪製的程式節點圖》，PBSOI Paper 02。
3. Neo.K，《程式本體反演：從可執行投影重建可觀測程式本體》，PBSOI Paper 03。
4. Neo.K，《從程式碼到意圖：程式概念的歷史轉換與後文本時代》。
5. Neo.K，《多重投影程式論：原始碼不再是程式本體》。
6. Neo.K，《程式語言設計風格的多軸形態空間》。
7. Neo.K，《基本計算單位的歷史轉換：從指令、函數到張量、意圖與世界狀態》。
8. Neo.K，《穩定核心與動態表面：自適應程式語言的分層設計》。
9. Neo.K，《空間狀態論：異質底空間、嵌套尺度與空間改寫算子的統一方法論》。
10. EveMissLab，RepoLumen / Repo Semantic Teaching Layer v0.10。
11. EveMissLab，Semantic Graph PoC v0.1。
12. EveMissLab，CISG RepoLumen PoC v0.1。