lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


A table is a table. There is no such thing as a sequenced table. If you have:

t = {1, 2, 3, 4}
print(#t) -- 4
t.foo = 2
print(#t) -- 4
print(t[4]) -- 4
print(t.foo) -- 2
-- continuing for below:
t[5] = 5
t[7] = 7
print(#t) -- 5
t[6] = 6
print(#t) -- 7
t[6] = nil
print(#t) -- 5

for i = 8, 2000 do
 t[i] = i
end
print(#t) -- !! 2000

As demonstrated, #t is not reliable if your table has the potential to hold nil (PiL mentions this, IIRC). I just ran this on the Lua site's demo, with _VERSION being 5.3

- Advert

On Sat, Jan 20, 2018 at 12:58 AM, Soni "They/Them" L. <fakedme@gmail.com> wrote:


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.