Re: Tables as vectors weirdness

["Thomas Lefort" <thomas.lefort@...>]

> The Lua manual states:
> "The length of a table t is defined to be any integer index n such that
> t[n] is not nil and t[n+1] is nil"
>
> But even *that* clearly isn't the case since # for an empty vector is 0
> (which is nil).  So, even the Lua definition of # violates its
> preconditions.
>

You do have a point here; this definition has to be revised. Still,
the manual quite clearly describes the canonical case:

  "For a regular array, with non-nil values from 1 to a given n, its
length is exactly that n, the index of its last value."

As Diego stated, should should stick to this canonical case when
working with arrays. In any other case, the # operator is not very
helpful indeed, lest you define an adequate __len metamethod.

> I don't want to have to *care* about a vector index start *or* end.  It
> should be completely opaque.  The failure is that tables as vectors have
> whacky behavior:
[...]
> In short, using "vectors" in Lua is a minefield of weirdness for new
> folks.  Either the semantics need to be cleaned up, or it really needs
> to be split out into a separate syntactic structure/system/etc.

Lua arrays are a minimalist and peculiar feature which takes advantage
of the table implementation. They are offered as is. Yes, the Lua
beginner has to go over the weirdness and learn how to use them proper
(canonical case).

More to the point, because canonical arrays are limited in scope, one
has to learn how to mold arbitrary data structures from Lua's powerful
meta-mechanisms. See for instance the Sano Collections Framework [
http://sano.luaforge.net/documentation/sano.html ].

Finally, if you're considering learning and using the language, the
manual won't be enough material to understand the "Lua way", as I like
to call it. For that I strongly recommend Roberto's book "Programming
in Lua" [ http://www.lua.org/pil/ ].

-- 
-- Thomas