Divooka 管道的基於文字的虛擬碼

目的

基於文字的虛擬碼格式用於以簡潔、易讀且與實現無關的方式表達 Divooka 管道。它有三個主要目標：

清晰——傳達資料流，不受語法噪聲干擾
文件優先的設計——即使語法不斷演進，示例依然保持穩定
概念一致——強調變換，而不是控制流

這種格式不可執行。它是管道邏輯的語義表示，用於文件、設計討論和新使用者上手。它也不打算與實際的 Divooka 程式直接一一對應。

這類管道更具體地適用於資料流處理上下文。本文件可作為社羣就相關主題進行技術討論的指南。

核心模型

Divooka 管道的模型如下：

data source → transformations → output

每一步：

接收一個集合或流
應用一個變換
返回一個新的集合或流

語法概覽

1. 賦值

管道通常以一個具名繫結開頭：

images = load("input/*.png")

左側：識別符號
右側：資料來源或管道

2. 管道運算子

管道運算子（|>）表示從左到右的資料流：

processed = images
  |> resize(width=1024)
  |> convert("webp")

等價的概念模型：

convert(resize(images))

3. 變換

變換以類似函式的操作來表達：

filter(price < 100)
map(name, price)
group_by(category)
count()

它們是：

無狀態的（從概念上說）
可鏈式呼叫的
與順序相關的

4. 資料來源

常見的入口：

load("file.csv")
fetch("https://api.com/data")
stream("events")

它們表示外部或初始的資料輸入。

5. 匯點（輸出）

管道以副作用或輸出結束：

save(data, "output.json")
print(result)

或者以內聯方式：

data |> transform() |> save("out.json")

6. 內聯表示式

簡單的表示式可以出現在變換內部：

filter(age > 18)
map(total = price * quantity)

這些表示式是宣告式的，避免使用命令式結構。

規範模式

典型的 Divooka 管道遵循以下模式：

result = source
  |> transform_1(...)
  |> transform_2(...)
  |> transform_n(...)

save(result, destination)

設計原則

宣告式優於命令式

不展示迴圈、變更（mutation）或控制流結構。

// Avoid
for item in items:
  ...

// Prefer
items |> map(...)

線性可讀性

管道從上到下閱讀，反映執行流程。

最簡語法

只表示必要的結構：

賦值
管道運算子
變換

以資料為中心的思維

關注點始終是資料發生了什麼，而不是執行如何被管理。

適用範圍

這種虛擬碼格式最適用於：

文件

解釋功能
說明常見工作流
在不鎖定語法的前提下提供示例

設計與原型製作

在實現之前勾勒管道
討論變換與組合

新使用者上手

向使用者介紹 Divooka 的思維模型
降低真實語法帶來的認知負擔

非目標

這種格式有意省略了：

錯誤處理
併發語義
型別註解
控制流（if/else、迴圈）
效能方面的考量

這些屬於實際的實現層，而不是概念模型。

示例（端到端）

data = load("orders.csv")

summary = data
  |> filter(status == "completed")
  |> map(total = price * quantity)
  |> group_by(customer_id)
  |> sum(total)

save(summary, "customer_totals.json")

這個示例演示了：

資料攝取
變換鏈
聚合
輸出

總結

基於文字的虛擬碼格式為表示 Divooka 管道提供了一個穩定且富有表現力的層。它抽象掉了實現細節，同時保留了資料驅動工作流的基本結構。

在整個文件中，我們將廣泛使用這種格式來討論 Divooka 的各種功能和示例。