lua-users home
lua-l archive

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

On Dec 30, 2009, at 9:36 PM, steve donovan wrote:

> On Wed, Dec 30, 2009 at 12:05 PM, Philippe Lhoste <> wrote:
>> Perhaps the comment from ltable.c:
> Which is a clear statement about the current implementation. All in
> all, it's best to avoid holes. We could go to a lot of trouble to
> handle holey arrays, but their behaviour is not fully determined.
> BTW, Lua iterator sequences have the same problems with nil values,
> since they end the iteration.
> A map() function could easily generate lots of holes:
> map(tonumber,{'10','x','20','y'})  --> {10,nil,20,nil}
> I would suggest that the result here should actually be {10,20}, that
> is, if the function called by map() returns nil, then it should not be
> part of the result array.  We avoid holes, and get a convenient
> filter-map idiom.

Yes, that's been my conclusion as well though I don't really like it. I'd like to have filters that might produce nil -- particularly when dealing with multivalued iterators -- and handle the filtering separately but this seems the best compromise.

Lua iterations could have been defined as terminating upon receipt of no values from the iterator, but this has the problem that it's actually  bit more expensive to detect in Lua since you need to pass ... to select to count the number of values.