Re: A proposal for the confusing pseudo table ≈ array concept

[KHMan <keinhong@...>]

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.


--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia