Re: table.maxn...

Dirk, I like you–you're just curmudgeonly enough to be adorable :)

I do take your point, though. I could pretty easily build a metatable with entries for __newindex, __index, and __len, and maybe override or augment a few table functions to do exactly what I was talking about. This makes it much less likely to be something that will ever get folded into the spec and VM–even if such a VM-level implementation would be much faster and more efficient than writing the equivalent Lua code, it is a hit for everyone else who doesn't care, it has to be designed, implemented, tested, and maintained, etc.

And the truth is probably that the metatables would be fast enough 90% of the time, and metatables in under jit would probably be fast enough for another 9% at the top, leaving relatively few cases where it really matters.

On Tue, Jun 2, 2015 at 12:22 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:

2015-06-02 0:27 GMT+02:00 Brigham Toskin <brighamtoskin@gmail.com>:
> On Mon, Jun 1, 2015 at 3:07 PM, Roberto Ierusalimschy
> <roberto@inf.puc-rio.br> wrote:
>> > This was meant to be a question about tracking the physical number of
>> > non-nil entries in the internal table data structure. [...]
>> >
>> > This being the case, most of the gotchas mentioned above seem to
>> > evaporate,
>> > and the only reason not to do that that I can see is that it makes *ALL*
>> > table writes a tiny bit more expensive. [...]
>>
>> Another reason not to do so is that it makes '#' mostly useless for
>> sequences (which are the only reason for its existence).
>
>
> Oh, I don't know that's necessarily true. In the case where t is a sequence
> (with no non-numeric keys), then #t == numentries(t), sure. But they are
> answering fundamentally different questions. It's kinda like saying that
> pairs() is a bad idea because it makes ipairs() redundant for sequences.
>
> I could definitely see a use for knowing the total number of things in a
> table, versus knowing the sequence length of a table (Andrew Starks'
> "sequence with properties").

We have not had this topic for some time, but it always seems to involve
at least one fresh mind that forces the old hands to go once again over
material they had pinned down. So I say thanks for your contributions,
not only to this thread but some other recent ones too. Even when
I disagree, it remains fun to read them [3].

As for this topic: I've been on both sides, starting out on yours [1] but soon
moving to the point of view that no change is needed [2].

> Plus `#' uses the __len metamethod if it exists, which means you can get
> a non-zero length for a table that technically doesn't have any physical
> entries of any sort under any key.

Where does Lua itself actually use `#`? Answer for 5.3.0: in the table library
and in the internal user-accessible tables it keeps, e.g. command-line
arguments and the registry. The rest of the time it uses `rawlen`.

So if you have a __len metatmethod on a table that is not a sequence
and never will be a sequence, it is safe [4] to be used for any property
you might want to associate with the symbol "#". Such as:

address = function(obj)
obj = tostring(obj):match"0x[0-9a-f]+"
return obj and load("return "..obj)()
end

[1] http://lua-users.org/lists/lua-l/2010-12/msg00187.html
[2] http://lua-users.org/lists/lua-l/2010-12/msg00756.html
[3] http://lua-users.org/lists/lua-l/2010-12/msg00594.html
[4] Modulo being a mere implementation detail not guaranteed
in the manual, of course. Some future implementation might in
some other place rely on __len returning a non-negative integer.

Brigham Toskin