Wiki 页面
有一些 Lua wiki 页面和项目我参与过。
代码与项目
通用主题、模式、技巧和设计
对其他文档的评论/注释
Lua 5.3 愿望清单
这里有一些让我恼火的事情,虽然我不确定该如何处理所有这些事情。
- 回溯信息可能需要一些改革。
- 我对元方法有疑虑。尽管它们很有用,但它们使语义更加复杂。
- raw 函数与非 raw 函数及语义的泛滥。另外,“rawtostring”在哪里? [LuaFiveTwo]。
- 我不明白为什么在 5.2 的 table.* 函数中会做出部分考虑元方法的更改。 [9][10][11]
- __index (与提议的 __getindex 不同) 不完全拦截表访问 (因此有代理表)。
- 曾有提议允许 'a:b()' 不依赖于 'a.b' (例如 __mcall 或 __mindex 元方法) [12]
- NamedParameters 作为表似乎很笨重。这对 LuaJit 优化有什么影响?将一个函数从无名参数转换为命名参数是其接口的根本性改变,不可掉以轻心。
- 版本问题仍有待解决。 ModuleVersioning/LuaVersionCompatibility。 5.2 是一个破坏性变更,并且在 LuaJit 中不支持。像 Perl 6 这样的其他语言有 "use v6;" 这样的语句来表明代码是 Perl6 而不是 Perl 5。 `_ENV = require '_G53'`?
- Lua 语法不总是作为 DSL 的理想选择。考虑表示像 PHP 这样的东西,其中控制结构嵌入在树节点中,但 Lua 中的 StatementsInExpressions 不够流畅。Lua 的逗号也会弄乱 [13]。与 Lisp 的 s-expressions 或 Ocaml 相比。
- 退出时清理 (ResourceAcquisitionIsInitialization)。典型的例子涉及文件句柄,如 file_slurp 的 readfile [3]。一个更简单的解决方案是 Google Go 的 "defer" 或 D 语言的 "scope(exit)。
- `local ok, err = f(); if not ok then return ok, err end` 是一个常见的习惯用法。应该让它更简洁吗?
- StringInterpolation 对于局部变量没有真正好的解决方案。某种类型的编译时预处理步骤,它将 `printf "${x},${y},${x}"` 这样的表达式扩展为 `printf("${x},${y},${x}", x, y, x)`,然后在运行时评估,这可能是一个不错的折衷。
- 前向声明的局部函数看起来像全局定义。注释或语义编辑器可以提供一些帮助。
local two
local function one() two() end
function two() one() end
Lua 5.2 愿望清单
注意:以下列表可能未完全更新以反映最终的 5.2.0 版本,可能需要进一步清理。
我想做的这些更改已包含在 5.2 的工作版本中 (LuaFiveTwo)
- 模块系统改革 - 使模块系统更一致 - 请参见 LuaModuleFunctionCritiqued。5.2 现在弃用了 module 函数及其类似物。有些人希望改进而不是废除 module 函数,但对于具体如何改进并没有达成共识。
- 环境改革 - 我支持 _ENV 提议,因为它简化了词法分析 (LuaInspect, LuaFish/luaanalyze) 和编译 (LuaToCee)。我认为这与一个更普遍的问题有关,即堆栈级别 (请参阅上面的回溯点)。我也同意 _ENV 很难看,大多数用户代码可能不应该使用它。
- C 函数改进 -- 与 lua_cpcall 不同,避免在 C 函数中进行分配 [15] (以提高性能和避免错误处理中的复杂性),并支持在保护调用中处理多个参数和返回值。在 LuaFiveTwo 中,lua_cpcall 被删除并替换为不再分配的 lua_pushcfunction,并通过 lua_pcall 支持多个参数和返回值。
- Lua 函数缓存 - 现在需要手动将函数实例化移出内层循环的情况减少了,因为函数现在被缓存了。然而,这个特性可能没有被充分利用[16]。
- BitwiseOperators 标准库。5.2 现在实现了这个。我曾以为 Lua 社区已经统一了 Lua Bit
Op (由 LuaJIT 支持并取代 lbitlib)。请参阅 BitwiseOperators/[5]。5.2 和 LuaJIT 的 bit 库对大多数情况来说可能都很好,并且可以编写兼容两者的代码:`local band = bit.band or bit32.band`,只要您避免不兼容的情况。应该添加 get/set 位域操作吗? [17] - 表的 __len 元方法 (以及 __pairs -- GeneralizedPairsAndIpairs)。然而,这让我有些犹豫,因为它打开了一些问题。我们应该有一个 rawlen (类似于工作版本中的 lua_rawlen) 吗?为什么 pairs() 会观察元方法但 next() 不会? Lua 表仍然不能真正虚拟化 (LuaVirtualization)。"table" 函数应该识别元方法吗?--可能不 [18]。
- 将所有 Lua 操作暴露给 C API - 扩展 C API 以支持缺失的运算符 [19]。 LuaFiveTwo 现在支持 lua_compare 和 lua_arith。我这样做的主要动机是简化我的 LuaToCee 输出。它也使事情变得正交,并且 Lua 实现起来相对容易。有些事情可能仍然缺失,例如 C 函数中的尾调用 [20]。
- 字符串中的**十六进制转义**有时很方便 (避免转换为十进制),特别是在读取文件或通信流时,这些文件或通信流的规范包含十六进制格式的字节,或者其单个位具有重要意义。当然,您可以使用辅助函数,`hex 'cdef'` 或 `binary '0101'`,但为什么需要它。
- 有些人要求 ContinueProposal。我倾向于发现从嵌套循环中跳出更常见。这是我关于将嵌套 break+continue 推广为单个构造的提议: LuaList:2010-11/msg00556.html 。另请参阅 GotoStatement。
- 零散的小事:
- 关闭管道返回退出状态
- 防止 Lua 标准库 ([21]) 触发 C 库中的未定义行为,例如 `os.date`。我认为,除了 debug 模块外,标准库永远不应因无效输入而崩溃。
- 将 lua_typerror 重命名为 lua_typeerror [22]。实际上,该函数现在已弃用。
- "package.loaders" 命名不当 [23][24] (package.loaders 包含 searchers 而不是 loaders)。
- 其他事情 我不常遇到,但我觉得还不错:允许更多的 yield 操作 (包括 PcallAndCoroutines),xpcall 接受像 pcall 这样的参数,Lua 解释器中非字符串错误消息,瞬时表 (改进弱表垃圾回收)。
- `luac -l -l` 目前是未公开的 (在 5.2.0 中完成)
- 将无法识别的转义序列视为错误? LuaList:2010-10/msg00449.html
- 克服局部变量数量 [25] 和连接 AssociativityOfConcatenation 的实现限制尚未实现,但 LuaFiveTwo 正在增加 "每个块的最大常量数从 2^18 增加到 2^26"。
这里有一些未在 5.2 中解决的旧想法,我还没有决定将它们移到 5.3 的愿望清单
RecentChanges · preferences
编辑 · 历史
最后编辑于 2015 年 1 月 1 日下午 8:13 GMT (差异)