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

[Tim Hill <drtimhill@...>]

> On Jul 21, 2016, at 10:09 AM, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
> 
>> 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
> 

But that would still leave the general case of {f()} unsolved :(

—Tim