lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Dec 31, 2009, at 9:05 AM, Florian Weimer wrote:

> A couple of weeks ago, I caught up with several months of mailing list
> postings, and I noticed that this particular topic (storing nils in
> arrays) reoccurred pretty often.  I don't think that Lua's behavior is
> improper, but it seems to puzzle users quite a bit.  In this light,
> more predictable behavior would likely make the language easier to
> use.

I agree that the behavior is appropriate and well-defined. Complaints that #t doesn't have a specified result if t has holes do not indicate a problem with the definition. The definition bounds the results in that case but does not specify them because doing so would have performance costs elsewhere.

I also agree that this bites people more than is perhaps desirable and creates a pitfall for which the work arounds are vague and/or require extra care. Arguably something like the old setn/getn behavior was clearer. I don't have an exact prescription for what would need to happen to Lua to make this work, but if one could simply tell people "you need to use table.setn to set the length of the table if the table has holes"  that might help. Alternatively, this might also be addressable with a standard array userdata type once things like ipairs virtualization is in.

Side note to Mike Pall on that subject: You mentioned the possibility of teaching LuaJIT about a matrix userdata type so that it could optimize it. How hard is it to teach LuaJIT about specific userdata types?

Mark