Module Compiler
模組語法編譯器
Module Compiler
人類可操作的模組語法 → 魔網語 (ArcSyntax) 的轉譯核心。負責把編寫者的意圖封裝為可送出的格式。
world.err//MODULE_04//04.1
READINGCORE · 核心STATUSLIVE · 已上線
🖥️ 04_INTERFACE_AND_TERMINALS · 04.1
魔法書系統架構
Grimoire OS Architecture
- 模組語法編譯器
- 魔法書架構
- 底層安全介面
- Grimoire Architecture
魔法書，是靈魂向世界遞交請求的方式。
原核語不可記誦、不可人工編寫——人類意識若直接觸及，將導致靈魂崩裂或魔能暴走。魔法書 (Grimoire) 因此被設計為人類施法的最低安全介面，本質上是一台模組語法編譯器，將人類可操作的語法安全轉譯為魔網能讀的指令。本篇拆解魔法書的內部模組、運作管線與算力邊界。
§ 1
系統定位與核心模組
System Positioning
現代施法不直接呼叫原核語 (Prime Root)——它屬於世界本體的底層語法，既不可記誦，亦不可人工編寫。魔法書作為人類施法的最低安全介面應運而生，其本質為一台模組語法編譯器 (Module Compiler)，負責將人類可操作的語法，安全轉譯為系統可讀的指令。內部包含四個主要功能模組：
Syntax Validator
語法檢查器
Syntax Validator
在送出前驗證模組是否存在、參數齊全、值域合法、語法閉合——僅針對表層邏輯做檢查，不涉及語意。
IR Generator
ArcSyntax 生成器
IR Generator
把模組語法與波型參數編譯為魔網專用的中介表示 (Intermediate Representation)，等待節點解析。
Soulwave Calibration
靈魂波型校準
Soulwave Calibration
首次啟用時錄製施法者的靈魂波型，建立個人專屬的本地字典 (Local Dictionary)——日後施法只比對波型捷徑，避免每次重跑語意解析。
§ 2 核心運作管線 · Execution Pipeline——當施法者啟動魔法書進行施法時，系統的資訊流動如下：
🧠 施法意圖Intent
🧩 模組語法呼叫Module Syntax Call
📘 魔法書語法檢查、參數填值與 ArcSyntax 生成
🌐 魔網語意判定、能量調度與核心調用
✨ 原核語世界執行層
§ 2.1
語法合法性檢查
Syntax Validation
魔法書在接收指令後，僅針對表層邏輯進行驗證——它不知道「火焰能不能存在」，只知道「這段語法寫得對不對」。
CHECKS
負責檢查
- 模組是否存在
- 參數數量是否正確
- 值域是否滿足必填條件
- 語法是否閉合
- 有無明顯的未定義或格式錯誤
BLIND SPOTS
不予檢查（盲區）
- 無限迴圈
- 自相矛盾的物理現象（如：負溫度的火焰）
- 無法執行的邏輯
- 要求世界系統執行不可能的任務
§ 2.2
波型參數讀取
Soulwave Parameter Read
為填補模組所需的參數 (Arguments)，魔法書會讀取施法者的靈魂波型——但用途僅限於參數填值。
魔法書不會解析施法者「在想什麼」。它讀取的是施法者呼叫模組時，由大腦意圖牽動靈魂波型所形成的即時調變（語意變數）。以下為「火球術」的範例映射：
radius
火球大小
映射至施法者認知的「空間佔比」訊號。
color
火焰顏色
映射至施法者認知的「燃燒狀態」訊號。
temperature
溫度
映射至施法者認知的「熱量級別」訊號。
vector
推進方向
映射至施法者主觀認知的「前方向量」訊號。
CAST_FIREBALL · ArcSyntax Compile Resultarcsyntax (simulated)
CAST_FIREBALL {
radius = 0.5m
temperature = 1800K
pressure = 1.4 MPa
vector = (0,0,1)
}
§ 3
硬體定位與算力邊界
Hardware Limits
魔法書的定位接近於專用型語法處理裝置，而非完整的世界模擬器。
Scope
能力與責任邊界
魔法書能處理型別檢查、參數映射、單位轉換與低階邏輯判斷；但無法進行高維現象模擬、巨量數值積分、原核語生成，或自行判定世界是否應該接受某個現象請求。
因此，魔法書的責任止於「產生可提交的 ArcSyntax」。請求是否具備語意合理性、能量可行性與物理成立條件，皆由魔網核心結構進行最終裁決。
若以現代資訊系統類比，魔法書更接近前端編譯器與本地參數處理器；ArcNet 則是負責語意裁決、資源調度與現象執行的後端環境。