Re: lua-5.1-alpha: length operator on tables (arrays) and nil values

[Ben Sunshine-Hill <sneftel@...>]

On 9/14/05, Bilyk, Alex <ABilyk@maxis.com> wrote:
> I also find this a problem, at least for myself. We have all sorts of explanations why such is the behaviour of #, but It's just plain counterintuitive to say the least. If not going into reading the manual as to why such is the behavior, the results produced by the cases below make no sense whatsoever and seem totally random. This doesn't click well in my mind with the bulk of Lua, which I find rather simple and intuitive.
> 
> I think the problems stem from the fact that a vector and a hash under the hood are presented at language level as a single concept of a 'table'. It would be easier to implement and maintain, it seems, two separate language concepts of a vector and a hash, rather then doing all sorts of acrobatics in attempts to present them via a single language construct.

I agree for the most part, but I'd suggest that Lua doesn't need
separate vector and hash types; it needs separate tuple and hash
types. It already /kinda/ has tuples, in the form of argument passing
(for function args and return vals) and multiple assignments, but it's
careful not to make those tuples into a full type. If "tuple" were a
type, of course, # could have (yet) another meaning which acted just
like you'd think.

Personally, BTW, I don't think that adding an operator which
polymorphically tells you either about the computer architecture, the
length of a string, or the low-level structure of a hashtable is
particularly useful, but the lack of tuples makes its semantics even
more confusing.

Ben