lua-users home
lua-l archive

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

Recently I began using Lua again in a real product, my last serious use
being at the time of version 4.0.  From the perspective of 4.0 to 5.1,
lists have gone from tolerable to bad with regard to nil element
support.  As is well-documented and discussed frequently, a nil will
foil any of the following:

    #t                 -- non-deterministic
    unpack(t)          --       ""
    ipairs(t)          --       ""

Common ways in which such lists are created include:

    { 2, nil, 'bar' }  -- literal list with nil
    { f() }            -- capture function return vals which include nil
    { ... }            -- capture function/chunk args which include nil

Programming in Lua refers to nil in a list as a "hole", but that is from
the perspective of Lua's table representation which cannot distinguish
nil-valued from nonexistent keys.  From the view of the list creator,
why should either of the following be considered as having holes?

    x = { 2, nil, 'bar' }
    t = { 2 }; table.insert(t, nil); table.insert(t, 'bar')

Clearly they are not sparse as constructed.  Stepping back, a list is
generally defined a series of values.  Lua nil is a first class value--
an incredibly useful one-- which should not render lists practically

I don't have a proposal for solving this in some efficient and
backwards-compatible way, only a bare request: make operations on lists
with nil work out of the box in the obvious way.  The current behavior
is a trap for the Lua novice and sends the expert straight to his bag of
tricks for a workaround.  The experts come up with different solutions,
causing interoperability problems between pieces of code.  This
situation isn't acceptable for a data type as fundamental as a list.

Like most in the community, I will have my pet list of small changes I'd
like to see in 5.2, but honestly if this was the only issue addressed I
would be happy.