John Belmonte

wiki

Lua 使用者，wiki 簾幕背後的男人。（挑戰：快速唸出十次「lua 使用者」）

我透過成功的遊說影響了 Lua，以下是幾件事：

• [使用表格作為全域範圍]（Lua 5.0）
• 字彙範圍（Lua 5.0）
• 布林型態（Lua 5.0）
• 使用標準授權（Lua 5.0）
• 增量垃圾回收（Lua 5.1）
• 在顯示錯誤物件時，遵循 __tostring（Lua 5.2）
• [範圍退出掛鉤]（Lua 5.4 待關閉變數）

簡報 / 出版品

• 文章：[結構化並行和 Lua]（2022）
• 章節：Lua 中的例外處理，[Lua 程式設計寶石]（2008）
• 簡報：[Lua 中的例外狀況形式]，第二屆 Lua 工作坊（2006）

我的頁面（或至少是我開始的頁面）

• LuaScoping、LuaInRealTimePrograms、LuaPowerPatches、BooleanTypeProposal、LuaLicense、CountingFromOne、LuaFunctors

我在 lua-l 上的貼文 [1]

最愛的 lua-使用者 wiki 頁面

• FiltersAndPipesReloaded
• TextTemplate

lua-users.org 是...

• （不）受歡迎的 [2]

我認為 Python PEP 的 [3] 是很好的資訊來源。找出 Python 有哪些缺陷，以及如何修正。了解 Python 如何實作最新的語言趨勢。

我想提一下一個奇妙的 wiki 實作屬性（大多數），這可能不是很明顯。它們會遺忘過去。儘管每個頁面都會維護編輯記錄，但它們會隨著時間推移而消失。因此，已刪除的錯誤、 unkind words 和無用的材料會真正消失，除非有人明確採取行動來復原或封存它們。這與寄件清單或新聞群組的概念完全不同，在公共論壇中，每個字元都可能被封存到文明結束。一篇與此主題相關的有趣文章是辯護 DELETE 金鑰 [4]。

以下是使用 unix wget 指令製作此 wiki 靜態複本以供離線瀏覽的方法。當然，離線時無法編輯或搜尋 wiki，所以這會讓事情變得沒那麼有趣。

wget --mirror --html-extension --convert-links https://lua-users.dev.org.tw/wiki/

JOHN'S LUA WARTS

• 表格建構函式會遺失順序列的長度資訊。當表格採用表格建構函式定義時（例如 { x = 10; 'foo', 5, bar() }），核心在建造表格時所知的清單部分的長度會被捨棄。長度運算子 (#) 可以正確地推斷其長度，但僅限於序列中沒有 nil 值時。（解決方法可能有點笨拙，Lua 5.2 中的 table.pack 將包含僅限序列的表格。）

• 沒有有效率且簡潔的清單反覆運算。「for i=1,getn(t)」成語很冗長，如果不小心使用，需要針對每個項目執行全域表格查詢。foreachi 成語由於每個項目會產生額外的函數呼叫開銷而沒有效率，且因為需要定義一個函數物件而不簡潔。我已經實作一個新的 for 構造作為解決方案，請參閱 LuaPowerPatches。（在 Lua 5.1 中，成語已變更，但問題依然存在。我們現在使用「for i=1,#t」或「for _,item in ipairs(t)」。）

這些問題很醜陋，但可以忍受

• 從 1 開始編製索引，並使用封閉範圍。從 1 開始編製索引的做法與大多數使用中的語言相反，而 Dijkstra [5] 也提出了簡潔有力的論點來反對這種做法。在 Lua 中，封閉範圍用於「for」構造和函式庫函數，很不方便的 (n, n-1) 代表長度為零。正常程式碼通常需要進行 +/-1 的索引調整。（請參閱 CountingFromOne。）

• 清單運算不支援 nil 元素。如果清單包含 nil 元素，則 # 運算子和依賴於它的函數（例如 unpack 和 ipairs）會是不確定的，或者乾脆忽略尾端的 nil。Nil 是有用的值，而這個基本資料類型的合理行為不應該受到 Lua 表格實作的阻礙。（Roberto 承認由於這個問題，nil 不是一級值。）如果表格建構函式不會遺失序列長度資訊（請參閱上方），則可以相當容易地解決這個限制。

• Lua 核心和標準函式庫不會列舉例外。Lua 核心和標準函式庫可能引發的錯誤集合並沒有列舉出來。如果應用程式想要捕捉特定錯誤，則必須使用解析例外字串的脆弱作法。

• 順道一提，更普遍的建議可能是對我的頁面進行「追蹤改革」。例如，Lua 會使用字串例外串接檔案路徑，甚至會截斷那些檔案路徑。--DavidManura

已被解決的歷史遺留問題

• 全域範疇的處理方式特別。儘管全域範疇在許多方面可以視為一般表格，但使用者定義的事件會採用不同的處理方式。（已在 Lua 5.0 中修復。）例如，以下各行會呼叫不同的指派事件

        a = 5
        globals().a = 5

• 沒有詞彙範疇。與表格一起使用的上值功能提供一種詞彙範疇的形式，但僅限於存取次一層的範疇。（已在 Lua 5.0 中修復。）

• 沒有使用者定義的循序。缺乏使用者定義的循序掛勾，讓我們無法建立有用的代理表格和清單。（這在 Lua 5.0 中修正了。）

• 將值 nil 用於 false。無法區分不存在的變數和從布林值表達式指派的變數。（請參閱 BooleanTypeProposal。這在 Lua 5.0 中修正了。）

• 實作中的類型控制不佳。實作沒有提供編譯選項來（完整）控制 C 類型用法。例如雙精度和長類型被廣泛地引用，導致某個平台發生問題。（從 Lua 5.0 開始有了很大的改善。）

• 無法覆寫表格或字串上的長度運算子（＃）。最明顯的是在表格的情況下，這會阻礙通過 Lua 程式碼建立自訂類似清單的物件。（這在 Lua 5.2 中修正了——至少對於表格是如此。）

• lua_tostring 不遵守 __tostring 元表掛勾。C API 中的 lua_tostring 和基本 Lua 程式庫中的 tostring 並不相等。前者不遵守 __tostring 掛勾，這對於使用者定義類型的偵錯和錯誤輸出，以及一般使用使用者類型模擬字串而言很重要。舉個問題的範例，lua 命令列詮釋器在遇到未攔截到的例外狀況時，會使用 lua_tostring，因此沒有辦法將非字串例外物件的明細傳達給使用者。（在 Lua 5.2 中，有一個獨立的函式 luaL_tolstring，它會遵守 __tostring，且詮釋器例外處理程式似乎會使用這個函式。）

• string.format %s 沒有呼叫 tostring。（這在 Lua 5.2 中修正了。）

• 沒有範圍掛勾元機制。許多應用程式會將稀有資源暴露給指令碼環境，例如鎖定；檔案、記憶體和資料庫交易的控制代碼等。在使用之後，這些資源需要立即且根據決定性地釋放，而且不管程式中有任何異常狀況。此外，Python 的環境管理員（with 陳述式）展示此一功能的無盡使用方式。當然，只要 Lua 願意，就可以完成這些工作，但產生的程式碼難以遵循，容易出錯，且大量使用受保護的呼叫——限制協同例程的潛在用途。如果 Lua 提供一種方法來掛接到範圍離開事件，那就可以解決此一問題。請參閱 [Lua: 改善有決定性的資源清除]。（由 Lua 5.4 的「即將關閉」變數涵蓋。）