Talk:续体

建议本条目移动为“续体”

continuation 应译作“续体”而非直译的“延续性”，是一种表示计算上下文的数据结构，并不是一种性质。—以上未簽名的留言由OlingCat（對話｜貢獻）於2018年12月3日 (一) 17:17 (UTC)加入。

對於條目的修訂計畫

(感謝長期維護條目的 Mhss！)

有一些修正改進的地方，其中一些問題原先就存在於英語維基底本，而有些看起來是錯誤翻譯或容易誤解的翻譯。我這裡先做一個筆記，說明我為甚麼要對一些內容刪除編輯，或是我自己打算做甚麼，留給我之後當作修改參考，也供其他共同編輯的維基人參考。

我的一些擴充計畫

---

我希望我能慢慢幫條目增加下列內容：

• 補上一些控制算子的 reduction 語意（抽象機 small-step 語意在教學上也很常用，應該稍微提到就好）

• 簡單提及編譯實現策略（例如經典的 Cheney on the M.T.A）
• 簡單提及形式化語言、邏輯學皮爾士定律的關係
• 簡單提及 delimited continuation 及 effect handler，詳細的內容需要另一個主條目

这些扩展主题分别写在专门条目中吧，英文版就分列了多个条目。 果寂（留言） 2025年11月14日 (五) 08:32 (UTC)

多谢你对迄今为之的条目状态的善意评论，我从未接触过学术圈，不会继续跟进了。想来早年起步于协程的，对如何并发计算这个主题的探究，其牵连已经过多过重，而超出了独自个人的惯性舒适范围。我做英语翻译会在一个限度之内，就是常想一下如果英文中要表达我所翻译出的文字会不会这些写，由于从未接触过讲英语的人，经常无法达成所愿。希望将来的这个条目能符合某种既得应有标准，到时可以籍此领略异域风情增广学识。果寂（留言） 2025年11月15日 (六) 00:30 (UTC)

謝謝您在這個條目長期的翻譯、維護，以及協助合作編輯。我自己剛好正在學習這個領域的東西，所以比較有在追蹤這幾年對計算作用的研究動向，但我還是有很多要學習的，我嘗試盡量兼顧正確性跟面向大眾的普及性。

關於本條目的一些問題，我後來看了英文維基，發現其實是從英文版就有些地方需要釐清修訂。所以有的地方我會脫離英文版本，修改幅度會較大（中文版修繕到一定程度我再打算貢獻回英文維基）。我若對既有內容做出大的修改，我會在這裡給出理由，有任何建議、批評跟疑問都歡迎交流，期盼能夠營造維基友善合作的環境。--AsiloMubizu（留言） 2025年11月15日 (六) 08:15 (UTC)

@Mhss：，謝謝您翻譯的內容，不過我提一下我的想法。（我不是資訊工程背景的，有寫過程式。接觸過組合語言和C語言，但對於Scheme語言不熟悉，有接觸過續體）。有關此一條目，概述部份我可以理解。但往後的部份就不容易理解了，尤其是程式範例的部份，列出程式是要方便說明，讓讀者容易理解，只是我不熟Scheme語言（應該有些讀者也和我一樣），對於註解比較不足的程式，前後直接有關程式的說明也不多，我覺得這條目對一般讀者來說，可能真的有些難度。--Wolfch (留言) 2025年11月15日 (六) 13:57 (UTC)

熟悉组合语言和C语言就已经是同行了，Scheme语言一个特定圈子的标志，极简主义的一个流派。我也偏好极简但却是与之无关的隐式编程，其中做过最多努力的就是J语言了，万一让我推荐个普世的学习和认知基础的话，我会选择dc。我先给协程例子加了描述，当年知道续体这个词就是从协程条目链接过来的，按英文版例子照着执行时发现它把解释器也给一起退出了，现在的这个例子已经该算是我写的了，我一生无师，都是一点一点查文档熬过来的，翻译和修订Scheme条目是其副产品。果寂（留言） 2025年11月15日 (六) 18:50 (UTC)

是說我覺得 CPS 本身應該也需要一個主條目，CPS 的應用非常廣，從編譯器中間表達形式，到一些計算模型都有使用。其本身也是一種比較需要花時間理解的東西，它利用高階函數達成的IoC，反向地暴露出控制流跟依賴關係，理解起來是頭腦體操。而 CPS 跟 Monad、SSA、ANF 之間的關聯也值得指出（我記得好幾篇論文討論過，但這邊就先不附上了）--AsiloMubizu（留言） 2025年11月15日 (六) 17:22 (UTC)

CPS对于普通编程者是“callback hell”，最初所围绕的是一些纯粹的理论问题，一般编程涉及不到，而在特别专门的领域里的一些任务，可以按某种理念去做，也可以按其他对立理念去做，它们没有决出生死之前，对绝大多数外人而言都是别人家的好孩子。CPS在英文版里有对应条目，我乐观其成，就我个人而言，年龄和处境因素导致我还能努力的剩余时间不多了，我会搞些东西给自己当盖棺定论，轻易不会再分叉了。果寂（留言） 2025年11月16日 (日) 07:20 (UTC)

一些我打算刪除或是大幅修改的

---

刪除「續體是一種資料結構」的說法（已經完成）

條目開頭「續體是一種資料結構」的說法是錯誤的，漢語的說法是「續體可以由資料結構建構」。續體是一種概念，而不是指特定一種的資料結構。例如頭等續體可以經由 reduction semantics 呈現，這與所述「續體是一種資料結構」的直覺相悖，以下由 call/cc 舉例：

E[callcc (λ k . e)] → E[(λ k . e) (λ x . E[x])]

我想，作為一個條目的開頭，需要更泛化的去說明這件事情。「續體」本身是概念性的，可以由不同種類的語意定義。雖然，在實作上有些 runtime 會使用一些資料結構如 Linked List 來實現 continuation（即 Linked frames），但也能用 Contiguous stack，這樣就不需要把 Linked list；又或是 Monad 在程式語言中以 ADT 構造出的資料來呈現，以 Free monad 來說它可能會形成一棵樹。這些正說明了「續體是一種資料結構」這句話是錯的，我們應該說「續體可以由不同種的資料結構捕捉/呈現/建構」。我們不應該把特化的情況跟實現的細節，上升成為對這個概念的描述。

需要釐清「頭等續體」不總是 call/cc 「續體還被用來提及「頭等續體」，它是一種構造，賦予程式語言儲存在任何點上的執行狀態的能力，並在程式中後來的點上可能多次返回到這一點」頭等續體（first-class continuation）不一定都能恢復多次（即. 多發 multi-shot），實際上也存在單發／僅能恢復一次（one-shot）的頭等續體。這個誤解或許是來自於刻板印象，即是知名的 call/cc，它既能多發也是頭等續體。但出於效能或是正確性的理由，有一些 one-shot 的 first-class continuation 被提出，例如 Chez Scheme 的 call/1cc （其論文刊載為 Representing control in the presence of one-shot continuations）。

（ps. 「最多只能使用一次」這種限制就是一種Affine types 的體現，Affine types 的值仍然可以是 first-class 的。）

關於「程式語言的直接支援」章節（EDIT: 2025/11/15）

我會對這個清單做出較大的更動，以下詳述。 這個清單起初讓我困惑，因為它混雜了 call/cc、協程、生成器、Async/Await等等的語言特性，似乎不夠清晰。後來我查了英文版，發現這個列表在2006~2007年的版本主要集中在 call/cc。可能因為協程的表達能力與單發續延相似（文章下面附上），所以有貢獻者添加了相關內容。但這樣的做法讓列表變得雜亂，讀者可能會疑惑為什麼 call/cc 和生成器會放在一起，也會顯得「沒完沒了」。

這裡，我會說明我要怎麼更動：

1. 只保留支援call/cc算子的語言，並從「頭等續體」移動到「以當前續體呼叫」，這樣比較符合二十年前這個列表被創立的目的。
2. 在「頭等續體」製作表格，以描述不同種類的頭等續體（包含協程等等）。

協程與單發有界續體的對等形式，有以下論文提出(討論板這裡先不上詳細的引用格式，文章僅用標題也搜尋得到):

• Revisiting Coroutines
• Yield: Mainstream Delimited Continuations
• One-shot Algebraic Effects as Coroutines
• Expressive Power of One-Shot Control Operators and Coroutines--此條留言由AsiloMubizu（討論｜貢獻）於2025年11月15日 (六) 17:04 (UTC)加入。