 |
lua-l archive |
|
|
||
|
One of the things that I find makes Lua so simple and powerful to use is the fact that type is almost irrelevant, behaviour is the key. It doesn’t matter what something actually is, as long as it behaves in the way the thing manipulating it expects.
In the same way as an object can implement multiple interfaces in object orientated programming, without any difficulty, I can have a table that looks like both an array and a function at the same time. Imagine a caching function that remembers it’s values for the last n calls. Your proposal feels like a move away from this way of thinking, which to me does not seem a good idea.
I think my biggest objection to your idea is the different behaviour of pairs depending on the underlying type, because this means you need to know the underlying type at the point you manipulate the thing. I think a major point in the language is that you never have to know the underlying type.
I also have not experienced the difficulty you have had in explaining how tables work, and over the past 6 months I have taught 2 people Lua at different levels.
The main difficulty I have found with people is explaining that pairs() isn’t ordered. I think this comes from a general unfamiliarity with unordered data structures though.
Thanks,
Kev
Sent from my iPhone
> On 19 Jan 2018, at 10:26, Elias Hogstvedt <eliashogstvedt@gmail.com> wrote:
>
> Lua was my first language and the language I've been using the most for 10~ years. I want to point this out becuase I don't want to be the guy who's coming from X language that want changes in Lua because it's different from his favorite language. I'm not really expecting any change but it's fun to think about language design and I'm looking for feedback.
>
>
> I think there’s a need for arrays now, especially if we want to solve var args being a second class citizen. table.pack introduces the n field as a workaround for nil values in a table but this feels a bit like duct tape when we could just have an array type in Lua.
>
> 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"
>
> 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.
>
> "mylist = table.tolist(tbl)" - for converting table to list if the table is valid.
> "mylist = []" - to create a dynamically sized list.
> "mylist = [1,2,3,4,nil,6]" - to create a list that is 6 in length.
>
> 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.
>
>
> mytbl.varargs = table.pack(...)
> ======================
> function foo(@)
> mytbl.varargs = @
> print(mytbl.varargs[1])
> end
> foo(42)
> =======================
> >> 42
>
>
> local x,y,z = ...
> ======================
> function foo(@)
> local x,y,z = @:unpack()
> print(x,y,z)
> end
> test(1,nil,2)
> =======================
> >> 1 nil 2
>
>
> select(“#, ...”)
> =======================
> function foo(a,b,c,@)
> print(#@)
> end
> foo(1,2,3,4,5,6,7,8,9)
> =======================
> >> 6
>
>
> for i = 1, select(“#”, ...) do print(i, (select(i, ...))) end
> =======================
> function foo(@)
> for i,v in @:pairs() do
> print(i,v)
> end
> end
> test(1,nil,2)
> =======================
> >> 1 1
> >> 2 nil
> >> 3 3
>
> I believe this would simplify and make the language easier to understand.