 |
lua-l archive |
|
|
||
|
On 2018-01-19 10:51 PM, Elias Hogstvedt wrote:
The length of the array should be dynamic and not fixed size.
But wouldn't x.foo = 2 on a sequenced table also cause undefined?
I feel like you think the table module is only defined for pure sequences. It's not.
It's defined for sequences. That is, tables with no integer keys after the first nil integer key. It ignores the non-sequence part completely unless stated otherwise.
At least that's how I understand it. I may be wrong.
On Sat, Jan 20, 2018 at 1:39 AM, Advert Slaxxor <adv3r7@gmail.com <mailto:adv3r7@gmail.com>> wrote:
This is one reason why this'd require you to know if it's an array
or table:
x = array(10)
x.foo = 2 -- attempt to index a array value (global 'x')
n = 20
x[n] = 8 -- attempt to access array index 20, size is 10 (global 'x')
- Advert
On Sat, Jan 20, 2018 at 12:22 AM, Elias Hogstvedt
<eliashogstvedt@gmail.com <mailto:eliashogstvedt@gmail.com >> wrote:
Hi Kevin, I'm not sure I get what you mean. I agree with what
you're saying about Lua but I don't see how this will change
any of the behavior you're describing. pairs will still be
pairs and tables would behave like they always did. Why do you
need to know the type of the list? You are saying the type is
irellevant but at the same time that it is relevant.
On Sat, Jan 20, 2018 at 12:16 AM, Kevin Martin<kev82@khn.org.uk <mailto:kev82@khn.org.uk>> wrote:
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<mailto: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.
--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.