Re: Quest: real world "Lua array with holes" usage

[Roberto Ierusalimschy <roberto@...>]

> For my particular use case I made heavy use of "sparse things", from which
> Lua tables are awesome, where all computations are based on the keys,
> namely, with pairs() or indexing the relevant key. Also, I use "proper
> sequences" with Lua tables. In this case, table.pack and table.unpack are
> symmetric, and the relevant computation is given by the "order" of the
> keys, namely, with table.insert, table.remove, table.move etc that is by
> default, in this case, simple to understand. I never ever used a "Lua array
> with holes", where the ordering, or existence, of the keys is indeed
> relevant for computation. Precluding the use of __len or misbehaviour of  #.
> 
> Could you help me giving a (real world) counterexample?

The only real-world case that bothers me is when you want to collect all
the results from a function call, something like {f()}. If there is an
error, the standard protocol is to return (nil, msg), which would create
an array with holes. (Currently I think the correct way to fix this
would be to return (false, msg), not to change the behavior of lists.)

-- Roberto