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

[Elias Hogstvedt <eliashogstvedt@...>]

 >
   a = [1,nil,3]
    a[5] = 5   -- no error!
    print(a[5])
nil

Just imagine how a newbie will struggle with that, if even you
who claim to have been using mostly Lua for ten years have
difficulty grasping it.

> 1. Numerical indices from 1 to array length only.

This depends on if the implementation restricts the length or not. I didn't specify this, but I wasn't sure either until after the replies and now it seems obvious that it should be dynamic, at least by default. In your code this would set the length of the array to 5 so index 4 would be nil and index 5 would be 5.

> I find it confusing to call an array a list.

As you expressed for syntax, the name doesn't really matter to me either. I thought it would make sense to call it a list to differentiate from traditional arrays. When I think array I think of something that starts from 0, has a strict strict size/length based on its type. A list seems more broad.

> 5. Monopoly of list/array functions by the new array type, to the
extent of destroying many traditional ways of using a table.

Are you talking about functions like list.insert only working on lists and would error on tables? If we want to preserve backwards compatibility then these functions could also work on tables.

Can you also expand on the traditional way of using tables that this would destroy?

(offtopic: I'm using gmail and I'm not sure how to best reply to multiple emails and reply inline with quotes. So I'm trying to use a dark purple color and > as that's what i'm seeing on my end)

On Sat, Jan 20, 2018 at 1:20 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:

2018-01-20 13:41 GMT+02:00 Elias Hogstvedt <eliashogstvedt@gmail.com>:

> So as I've said before this is more for the people who are
> relatively new to Lua. (which might be an unpopular bias I guess).

The thing is, being relatively new to Lua is a state that passes.
I can still remember when I got to grips with the Lua all-purpose
table, (later) metatables, (about at the same time) userdata,
(much later) the generic 'for', (much, much later) coroutines,
(never quite completely) the C API, (probably forever beyond
me) the Lua source code, etc.

I.e. understanding tables is the pons asinorum of Lua. There is
no royal road.

In the long run, what matters is how powerful and convenient
Lua is for the day-to-day Lua user. In my case, so much so
that I can't even remember how I did it in Python eight years ago.

> I'm not sure about this either. if a list is constructed as [1,nil,3] then
> index 2 and 4,5,6,7,... will be nil. The length will be 3 but what happens
> to index 4 if you do list[5] = 5 ? maybe it should just become nil and the
> length becomes 5? As I was writing this I wasn't sure but nil seems to make
> the most sense in Lua.

    a = [1,nil,3]
    a[5] = 5   -- no error!
    print(a[5])
nil

Just imagine how a newbie will struggle with that, if even you
who claim to have been using mostly Lua for ten years have
difficulty grasping it.

> My hunch is that it would be a simpler implementation as you would no longer
> assume tables can also be arrays under some circumstances. I haven't really
> looked all that much at the Lua internals though.

Worth while attemping once in a blue moon, even though
when I do that, I tend to fall over daunted.

> - arrays would not have hash part, so can’t add extra info to them in
> named fields (pretty common thing in Lua I think)
This also is a useful feature of Lua I think but adding named fields
onto a sequential table is a bit ambigious in the first place.

XML does it, which is one of the reasons why XML to Lua
converters tend to be almost trivial.

> You'd have to make a table and put the array inside of it
> as you'd have to do with all the other types in lua.

Thank you for admitting that.

M'lud, I have no further questions.