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

[Dirk Laurie <dirk.laurie@...>]

2018-01-19 17:53 GMT+02:00 Jean-Luc Jumpertz <jean-luc@celedev.eu>:

> Frankly, this proposal makes sense, and I thinks bashers should read it carefully before criticizing it with that much energy… :-)

Frankly, Lua offers enough to address the need for lists,
and I think people who wish to change the language
should study the available mechanisms before proposing
breaking changes.

Let's ask ourselves what is possible with a list class. I'm doing it
in a live session; for the sake of those who want to experiment,
I append the module 'list' and the module 'dclass' on which it depends.

$ lua -l list
Lua 5.3.4  Copyright (C) 1994-2017 Lua.org, PUC-Rio
> x=list(1,2,3,nil,5,nil)
> x
list: 0x1efefc0
> #x
6
> x:concat" "
1 2 3 ⎕ 5 ⎕
> x:insert(5,'foo')
> x:concat" "
1 2 3 ⎕ foo 5

As you can see, this implements a fixed-length list with replacement of nil
by a string. _G.list is a shallow copy of _G.table with a __call metamethod
so that it can create a list object with _G.list as metatable.

(a)
> 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)”

No need to tamper with tables. Just tell you newbie to use your custom
'list' class and not call any 'table' functions.

Also, the existing table functions are not well suited to work with
fixed-length lists. For example:

    x=list(1,2,3,nil,5,nil)
    x:remove(2)
2
    x:remove(3)
⎕
    x[6]=6
    x:concat" "
stdin:1: invalid value (nil) at index 5 in table for 'concat'

(b)
> 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 (?)

No need to tamper with tables. Just tell your newbie to use your custom
'list' class and not call any 'table' functions.

(c)
> The length operator on tables would no longer work unless we set a metatable
> on the table with the length operator.

No need to tamper with tables. Just tell you newbie to use your custom
'list' class and not call any 'table' functions.

(d)
> _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"

No need to tamper with tables. Just tell you newbie to use your custom
'list' class and not call any 'table' functions.

(e)
> The list object would be constructed with the syntax [a,b,c] instead of
> {a,b,c} and can contain any value. However list keys are strictly numbered
> and ordered.

Is [a] a one-element list? Will fct[a,b,c] call fct with the list
[a,b,c] as argument
or will it be necessary to write f([a,b,c])?

(f)
> "mylist = table.tolist(tbl)"  -  for converting table to list if the table
> is valid.
Rather
   mylist = list.copy(tbl)

> "mylist = []"  -  to create a dynamically sized list.
> "mylist = [1,2,3,4,nil,6]"  -  to create a list that is 6 in length.

So a fixed-length empty list can't be constructed?

(g)
> Var args become a list object. Because of this I think "..." should be
> replaced with @. Here are some lua examples with the old method on top.

Let's wait for Lua 5.4. The grapevine message is that '...' will be revamped.