lua-users home
lua-l archive

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

On 20/08/2016 19:22, Soni L. wrote:



On 20/08/16 09:17 PM, Martin wrote:

On 16-08-20 07:04 AM, Soni L. wrote:

local len = 1
while (t[len] ~= nil) do
    len = len + 1
end
return len


You should probably return len - 1. Otherwise {} has len 1 and {1} has
len 2.

You're right.


Tables shall be k/v pairs. The concept of an "array" shall be userland.

They already are.

So if I understand right you offer just drop part of existing
functionality for the sake of conceptual clearness. I think this
decision is hard to accept for many users.



It is. But I can't come up with a better option.


Maybe stop fighting against the language and leave it as it is?

When I was a newbie in Lua (coming mainly from Java and C++ background)
I often tried to shoehorn familiar (in those languages) concepts and practices into Lua. Then I grew more familiar with the language and stopped trying that. I ended up with much more understandable and clean code, and also learned that OO abstraction is not always useful. 



This is the only reasonable way I can come up with to reinforce the
notion that tables are k/v pairs and nothing more. I mean, I can come up
with unreasonable ones too, from least intrusive to most intrusive:
Lua is not the most theoretically clean language around, but IMO is one of the most *practically clean* language. Most of the design decisions in its development have been taken with the aim of getting a minimalist AND practical language. Fulfilling a CS theoretical ideal, as far as I remember, IS NOT a goal of Lua team (and I appreciate that).
BTW, have you ever considered that Lua has no formal "language specification". Roberto has said many times that Lua is what the reference manual describes and he also said (IIRC) that "they are not into language specifications". This is a deliberate design decision.
Lua is full of delicate compromises and balances between theoretical "purity" and pragmatic usage, and that's why it is good and lean: it is neither a computer-scientist awkward toy nor a massive juggernaut of total pragmatism (where everything is built-in, even the kitchen sink). 

I think that many misunderstandings regarding tables and their usage
is that the reference manual is not very friendly for a newbie expecting
more traditional data structures. It took me several months to understand clearly what a table *really is* (in Lua "philosophical" sense, I mean): it is a (relatively) *low-level* data structuring mechanism.
The point is that a table is a Lua table, not something else. If you need a more traditional data structure you can implement it on top of that. When I need more abstraction in complex applications, I simply see tables as a low-level implementation mechanism. Otherwise, for simpler scripts or programs, tables are good as they are.
Remember that one of the goal of Lua team is to provide mechanisms, not policies.
Dropping a useful feature (#) just because you cannot frame it in a theoretically satisfying ideal is not useful for the general Lua community IMO.
BTW, if you feel the need of removing #, try writing scripts simply ignoring the existence of # and see if they turn out any better. If you are expert enough you could hack into Lua source and remove that functionality *and test whether your scripts end up cleaner*. 


- Put "LENGTH IS UNDEFINED" wherever the manual mentions table length.
- Remove list syntax. (you know, {1, 2, 3, 4, 5})
- Print "LENGTH IS UNDEFINED" to stderr every time the length operator
is used.
- Put the length operator behind a "feature gate" that needs to be
applied per chunk, otherwise the compiler tells you that "length is
undefined and tables are only k/v pairs" and stuff and refuses to
compile your code.



Cheers!

-- Lorenzo