Arrays and Tables

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Arrays and Tables

Dibyendu Majumdar
Hi,

I was looking to see if Lua ever had a distinct array type, and
reading the hopl paper it seems that Lua 1.1 indeed had distinct array
and table types but the two types were merged to a single table type
in Lua 2.1.

I think the Lua team believe this was the right decision - at least
that is the impression I get from various talks given by Roberto. I
wonder if the language would be more powerful if it had a distinct
array type.

I am not suggesting any change here ... as I believe it is never going
to happen. But I would be interested to know what Lua users think.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Arrays and Tables

Charles Heywood
Personally I feel like it would lead to more confusion (strangely, people think tables being a merge of arrays and objects being confusing) because tables are already optimized for array sections, right? I feel like the only change that would make sense is perhaps syntax-assisted `table.remove` and `table.insert` to remove the overhead of repeated indexing of `table` - but this is already achievable using bytecode- and manual-optimization.

On Sat, Jun 24, 2017 at 5:58 PM Dibyendu Majumdar <[hidden email]> wrote:
Hi,

I was looking to see if Lua ever had a distinct array type, and
reading the hopl paper it seems that Lua 1.1 indeed had distinct array
and table types but the two types were merged to a single table type
in Lua 2.1.

I think the Lua team believe this was the right decision - at least
that is the impression I get from various talks given by Roberto. I
wonder if the language would be more powerful if it had a distinct
array type.

I am not suggesting any change here ... as I believe it is never going
to happen. But I would be interested to know what Lua users think.

Regards
Dibyendu

--
--
Ryan <[hidden email]>
Software Developer / System Administrator
Reply | Threaded
Open this post in threaded view
|

Re: Arrays and Tables

nobody
In reply to this post by Dibyendu Majumdar
On 2017-06-25 00:58, Dibyendu Majumdar wrote:
> I wonder if the language would be more powerful if it had a distinct
> array type.

I think not, I don't see anything useful that this would add.  Tables
work just fine as arrays (and they're optimized for that use.)

Just having a different type doesn't improve anything.  (If type errors
count as an improvement, using a metatable as a type tag & checking that
already works – that doesn't need a new type.)  What actually adds value
is library functions and built-in features you no longer have to worry
about.  But the library functions can just as well be written to operate
on (array-like) tables, so there's no need for a new type from that
aspect.  Which leaves built-in features as the last possible reason.  If
I go through the list of array-specific functionality that I might want
– bounds checks (use __[new]index metamethod), multidimensional indexing
or range selection or ... (use a/several method(s)), ... – I don't see
anything that's not already doable in a reasonably efficient & usable
way.  Really funky features (arbitrary transposition/index reordering,
slicing, ...) are complex either way.  I don't see any obvious advantage
to implementing them on a "real" array type vs. tables.

Coming from a different perspective:  How would you implement the array
type in C?  You have pointers, structs, and arrays / memory regions as
primitives to build upon.  No matter how you implement it, you can
essentially do the same thing using tables as the sole primitive.
Structs are obvious, as are arrays.  Pointers to (the start of) things
are also obvious: just use the reference.  Pointers _into_ things may
seem hard at first, but you can view tables as non-overlapping memory
segments or mappings of unspecified / arbitrary size, which makes the
solution obvious:  Use pairs of (base pointer, offset) or { base =
some_table, offset = int }.  (Which is conveniently a thing that can be
pointed at, so pointers to pointers to … are also easy.  And if you
don't need that, you can usually fold this (base,offset) pair into the
parent structure to avoid allocating tons of tiny "pointer tables".)

So any array type implementation that you write in C can be written in /
translated into Lua as well.  The translation does not involve any
costly emulation of "missing features", so it shouldn't be prohibitively
slow or huge.  Which means you can just build the array type and all its
functionality on top of tables and don't need a separate primitive type.

-- nobody

Reply | Threaded
Open this post in threaded view
|

Re: Arrays and Tables

Roberto Ierusalimschy
In reply to this post by Dibyendu Majumdar
> I was looking to see if Lua ever had a distinct array type, and
> reading the hopl paper it seems that Lua 1.1 indeed had distinct array
> and table types but the two types were merged to a single table type
> in Lua 2.1.

That is not true. Lua 1.1 had distinct notations for constructors of
arrays (lists) and records, but the underling table was already the same:

    So we took SOL’s syntax for record and list construction [...],
    and unified their implementation using tables: records use strings
    (the field names) as indices; lists use natural numbers

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Arrays and Tables

Dibyendu Majumdar
Hi Roberto,

On 25 June 2017 at 08:03, Roberto Ierusalimschy <[hidden email]> wrote:
>> I was looking to see if Lua ever had a distinct array type, and
>> reading the hopl paper it seems that Lua 1.1 indeed had distinct array
>> and table types but the two types were merged to a single table type
>> in Lua 2.1.
>
> That is not true. Lua 1.1 had distinct notations for constructors of
> arrays (lists) and records, but the underling table was already the same:
>

Ah, okay. I misunderstood following to mean that there were distinct types:

   The form ‘@[]’ was used to create arrays, as in ‘@[2,4,9,16,25]’.
   In such tables, the keys were implicit natural numbers starting at 1.
   The form ‘@{}’ was used to create records, as in ‘@{name="John",
   age=35}’. Such tables were sets of keyvalue pairs in which the
   keys were explicit strings.

Thanks for the correction.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Arrays and Tables

Italo Maia
I always thought lua approach on arrays was quite clever. I miss the fact that "non-arrays" cannot be counted with #, but beside that, all is fine.

2017-06-25 5:42 GMT-03:00 Dibyendu Majumdar <[hidden email]>:
Hi Roberto,

On 25 June 2017 at 08:03, Roberto Ierusalimschy <[hidden email]> wrote:
>> I was looking to see if Lua ever had a distinct array type, and
>> reading the hopl paper it seems that Lua 1.1 indeed had distinct array
>> and table types but the two types were merged to a single table type
>> in Lua 2.1.
>
> That is not true. Lua 1.1 had distinct notations for constructors of
> arrays (lists) and records, but the underling table was already the same:
>

Ah, okay. I misunderstood following to mean that there were distinct types:

   The form ‘@[]’ was used to create arrays, as in ‘@[2,4,9,16,25]’.
   In such tables, the keys were implicit natural numbers starting at 1.
   The form ‘@{}’ was used to create records, as in ‘@{name="John",
   age=35}’. Such tables were sets of keyvalue pairs in which the
   keys were explicit strings.

Thanks for the correction.

Regards
Dibyendu




--
"A arrogância é a arma dos fracos."

===========================
Me. Italo Moreira Campelo Maia
Co-fundador do Grupo de Usuários Python do Ceará
Secretário ForHacker (fb.com/ForHackerSpace)
Desenvolvedor Full-Stack, Escritor, Empresário, Visionário
-----------------------------------------------------
Meu Livro, Site, Blog
===========================
Reply | Threaded
Open this post in threaded view
|

Re: Arrays and Tables

Dirk Laurie-2
2017-06-26 3:26 GMT+02:00 Italo Maia <[hidden email]>:
> I always thought lua approach on arrays was quite clever. I miss the fact
> that "non-arrays" cannot be counted with #, but beside that, all is fine.

Oh, but they can.

tbl = setmetatable({a="a",b="b"},{
  __len = function(tbl)
    local n=0
    for k in pairs(tbl) do n=n+1 end
    return n
  end})