John Belmonte

wiki

Lua-user, man behind the wiki curtain.

Challenge: say "lua-users" ten times fast.

My Pages (or at least pages I started)

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

My posts to lua-l [1]

lua-users.org is...

• (un)popular [2]

I've influenced Lua by successful lobbying for:

• consistent treatment of global scope (Lua 5.0)
• lexical scoping (Lua 5.0)
• boolean type (Lua 5.0)
• use of standard license (Lua 5.0)
• incremental garbage collection (Lua 5.1)

I think Python PEP's [3] are a great source of info. Find out where Python was flawed and how it's being fixed. Learn about Python's implementations of the latest language fads.

I'd like to mention a wonderful property of (most) wiki implementations that may not be entirely obvious. They forget the past. Although an edit history is maintained for each page, it fades out over time. So deleted mistakes, unkind words, and useless material really disappear unless someone explicitly acts to revive or archive them. This is quite a different concept from the mailing list or newsgroup where, in the case of a public forum, every word may likely be archived until the end of civilization. An interesting article related to this subject is In Defense of the DELETE Key [4].

Here's how to use the unix wget command to make a static copy of this wiki for offline browsing. Of course you can't edit or search the wiki when offline, so that takes the fun out of things.

wget --mirror --html-extension --convert-links http://lua-users.org/wiki/

Favorite lua-users wiki pages

• TextTemplate

PROJECT IDEAS

• Lua-based build system - something like Jam [5] could be done ten times better using Lua. It would also allow programs using Lua to easily share info with the build system... a big win for managing complex program data.
• alternate implementation of Lua in D - (waiting for incremental collector for D)

JOHN'S LUA WARTS

• Cannot override length operator (#) on tables or strings. Most notably in the case of tables, this obstructs the creation of custom list-like objects from Lua code.

• Table constructors drop sequence length information. When a table is defined by a table constructor (e.g. { x = 10; 'foo', 5, bar() }, the length of the list part-- known by the core when it constructs the table-- is discarded. The length operator (#) can correctly deduce it afterwards, but only if there were no nil values in the sequence.

• No efficient and concise list iteration. The "for i=1,getn(t)" idiom is verbose and when used carelessly requires a global table lookup per item. The foreachi idiom is not efficient due to extra function call overhead per item, and not concise due to the need to define a function object. I have implemented a new for construct as a solution, see LuaPowerPatches. (As of Lua 5.1, the idoms have changed but the issue still stands. We now have "for i=1,#t" or "for _,item in ipairs(t)".)

• lua_tostring does not honor __tostring metatable hook. lua_tostring in the C API and tostring in the base Lua library are not equivalent. The former does not honor the __tostring hook, which is important for debug and error output of user defined types, and in general the emulation of strings with user types. As an example of the problem, the lua command line interpreter uses lua_tostring in the case of uncaught exceptions, leaving no way to communicate the details of non-string exception objects to the user.

• string.format %s does not invoke tostring.

These points are ugly but tolerable:

• Indexing from 1 and use of closed ranges. Indexing from 1 is contrary to the most-used languages, and furthermore it is common knowledge among "non-programmers" that programmers count from 0. Closed ranges are used for "for" construct and library functions, with the uncomfortable (n, n-1) meaning zero length. Index adjustments of +/-1 are often required in normal code. (See CountingFromOne.)

• List operations do not support nil elements. The # operator and functions which depend on it such as unpack and ipairs are non-deterministic should a list contain a nil element, or else simply ignore trailing nils. Nil is a useful value, and reasonable behavior of this fundamental data type should not be obstructed by Lua's table implementation of it. This limitation would be fairly straightforward to work around if we could override the # operator on tables and if table constructors did not drop sequence length information (see above).

• Lua core and standard libraries do not enumerate exceptions. The set of errors which can be raised by the Lua core and standard libraries are not enumerated. If an application wants to catch a specific error, it must employ the fragile practice of parsing exception strings.

Historical warts which have been resolved:

• Global scope is treated specially. Although the global scope can be treated as a normal table in many respects, user-defined events are handled differently. (Fixed in Lua 5.0.) For example the following lines call different assignment events:

        a = 5
        globals().a = 5

• No lexical scoping. The upvalue feature used with tables provides a form of lexical scoping, but only for the case of accessing the next higher scope. (Fixed in Lua 5.0.)

• No user-defined iteration. The lack of hooks for user-defined iteration prevents us from making useful proxy tables and lists. (Fixed in Lua 5.0.)

• Value nil used for false. It's not possible to distinguish between a non-existant variable and a variable assigned from a boolean expression. (See BooleanTypeProposal. Fixed in Lua 5.0.)

• Poor type control in implementation. Implementation does not provide compile options for (complete) control of C type useage. For example double and long types are referenced extensively causing problems for certain platforms. (Much improved starting with Lua 5.0.)