On Fri, Jan 19, 2018 at 5:38 PM, KHMan wrote:
On 1/19/2018 11:53 PM, Jean-Luc Jumpertz wrote:
Frankly, this proposal makes sense, and I thinks bashers
should read it carefully before criticizing it with that
much energy… :-)
- Yes, having a single type of structured data is
intellectually elegant, but it brings lots of subtleties
that are not easy to understand for Lua newcomers.
- Yes, tables with holes are hell (see the number of
discussions on this list about ipairs or about the len
operator ;-)
- Yes, the "table" library is only related to sequences.
So thanks, Elias for having taken the time to write this! :-)
I'm not real enthusiastic about an array type. My personal
opinion of course.
(I don't think there are perfect vararg schemes either. Dots
are fine.)
I think Lua newcomers should not be the ones dictating the
shape or direction of Lua. Do we need to mollycoddle Lua
newcomers? Coders can't handle complexity? They are coders?
They need free their minds of internal blockages. :-) :-)
Le 19 janv. 2018 à 11:26, Elias Hogstvedt wrote:
In my experience with teaching other people Lua, a lot
of time is spent explaining the differences between
tables and arrays. There’s confusion about the length
operator, pairs vs ipairs, performance difference,
holes in tables, etc. The entire table library also
only makes sense on tables that are treated as arrays
and causes undefined behavior when used on tables.
So to solve this I would simply add an array type to
Lua which would help distinguish between tables and
arrays. To distinguish our new array type from arrays
in other languages that start from 0 and can only
contain a certain type of value we can just call it a
"list" instead.
Since all the table functions in Lua only work or make
sense on tables that are treated as lists we simply
rename _G.table to _G.list. The list object should
__index to _G.list so it's possible to do
“mylist:insert(2)”
Now that we have no table library we can create one
with functions that only made sense on tables instead.
table.get/setmetatable, table.rawget/set,
table.rawequal, table.next, table.rawlen, table.pairs
( ? )
The length operator on tables would no longer
work unless we set a metatable on the table with the
length operator.
_G.ipairs would no longer be needed and so using pairs
on lists would ensure correct order while on tables it
would not. We can also put _G.pairs in _G.list.pairs
to allow the syntax "for i,v in mylist:pairs() do"
I believe this would simplify and make the language
easier to understand.
