Re: New array type? (was: 'table' as fallback for tables)

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

Re: New array type? (was: 'table' as fallback for tables)

Jonathan Goble
The fact that this thread has ballooned into nearly 80 emails and is
still being debated suggests to me that perhaps we need to stop trying
to make tables do a job that they weren't designed to do, and instead
create a new array type separate from tables that is designed to do
that job.

Most languages have two distinct types for sequences and associative
arrays. Lua has just one type, the table, which is really good at the
latter, but doesn't do a very good job at the former. The ongoing
discussion proves that there is a need for a real sequence type
capable of holding `nil`, but I just don't think there is a good,
clean way for Lua, as it stands right now, to do that short of
creating a new type for sequences and deprecating tables for that
purpose (they would remain useful for associative arrays, of course).

A new type would have many advantages, chief among them elimination of
the need to store the length as a field in the table or metatable
(since the length would now be known and tracked by the C internals),
and elimination of the question of how to set the initial length from
a constructor (since array constructors probably wouldn't allow
explicit keys/indices).

I really think that this is the best way forward.

Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

Philipp Janda
Am 01.07.2016 um 03:01 schröbte Jonathan Goble:

> The fact that this thread has ballooned into nearly 80 emails and is
> still being debated suggests to me that perhaps we need to stop trying
> to make tables do a job that they weren't designed to do, and instead
> create a new array type separate from tables that is designed to do
> that job.
>
> Most languages have two distinct types for sequences and associative
> arrays. Lua has just one type, the table, which is really good at the
> latter, but doesn't do a very good job at the former.  The ongoing
> discussion proves that there is a need for a real sequence type
> capable of holding `nil`, but I just don't think there is a good,
> clean way for Lua, as it stands right now, to do that short of
> creating a new type for sequences and deprecating tables for that
> purpose (they would remain useful for associative arrays, of course).
>
> A new type would have many advantages, chief among them elimination of
> the need to store the length as a field in the table or metatable
> (since the length would now be known and tracked by the C internals),

One could add a table subtype (much like the integer subtype for
numbers) and stick the size field to the end of the table structure like
the payload for a userdata. This way we could re-use most of the table
implementation. In fact, arrays would behave exactly like regular tables
except when array-like behavior conflicts with generic table-like behavior.

Of course the `#` operator (and as a consequence the `table` functions)
should raise an error when applied to a non-array table without `__len` ...

> and elimination of the question of how to set the initial length from
> a constructor (since array constructors probably wouldn't allow
> explicit keys/indices).

Separating array literals and hash map literals might be worth
considering anyway (if Lua chooses to set an initial length in the future).

>
> I really think that this is the best way forward.
>

There are few smaller steps we can make:

*  Solve the `pack()`/`unpack()` symmetry problem.
*  Enhance the table library to allow non-sequence based array
implementations by adding a library metamethod `__resize` or
`__setsize`, so that `table.insert()` and `table.remove()` can adjust
the array sizes accordingly (`table.move()` is more complicated).


Philipp




Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

Dirk Laurie-2
2016-07-01 6:09 GMT+02:00 Philipp Janda <[hidden email]>:
> Am 01.07.2016 um 03:01 schröbte Jonathan Goble:
>>
>> The fact that this thread has ballooned into nearly 80 emails and is
>> still being debated suggests to me that perhaps we need to stop trying
>> to make tables do a job that they weren't designed to do, and instead
>> create a new array type separate from tables that is designed to do
>> that job.

> One could add a table subtype (much like the integer subtype for numbers)
> and stick the size field to the end of the table structure like the payload
> for a userdata. This way we could re-use most of the table implementation.
> In fact, arrays would behave exactly like regular tables except when
> array-like behavior conflicts with generic table-like behavior.

I like the basic idea, but we don't really need an explicit subtype, just
a specialized standard table. See below.

> Of course the `#` operator (and as a consequence the `table` functions)
> should raise an error when applied to a non-array table without `__len` ...

But breaking almost every existing Lua program just because its author
was not clairvoyant would be going too far.

The desired effect can be achieved by one function in the standard library.
That's all.

Well, actually two, since the second one is useful for any OOP.

~~~~
table.array(tbl[,n])

Sets or modifies the metatable of tbl so that #t always equals n,
__index points to the table library, and t:type() returns "array".
If n is not supplied, it is calculated from the current tbl so that
#tbl+1 is the first key absent from the table. Returns tbl.

table.type(tbl)

Returns the __name field in the metatable of tbl.
~~~~

The following matters would be implementation details.

1. How __len does it. (A field in the Table structure? An entry
keyed by tbl in the registry?)
2. Whether tbl is exempt from compaction when having more
than 50% holes.
3. Whether tbl would if necessary be resized so that the 'array'
part has size at least n.
4. Whether the table functions would exploit the optimizations
possible if #t is not greater than the size of the 'array' part.

Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

steve donovan
In reply to this post by Philipp Janda
On Fri, Jul 1, 2016 at 6:09 AM, Philipp Janda <[hidden email]> wrote:
> There are few smaller steps we can make:>
> *  Solve the `pack()`/`unpack()` symmetry problem.

This feels like a good one - otherwise I'm in the "Houston, I don't
really think we have a problem" camp.

function foo(...)
   local args = table.pack(...)
   for i = 1,#args do
     ..
   end
end

Easy to use and explain!

This table clearly has a metatable to override __len (the 'n' key
becomes an implementation detail and could be scheduled for
deprecation).

Hence, make __index point to table. This code should behave exactly as
Hisham expects:

local t = table.pack(10,nil,'hello')
foo(t:unpack())

> *  Enhance the table library to allow non-sequence based array
> implementations by adding a library metamethod `__resize` or `__setsize`, so
> that `table.insert()` and `table.remove()` can adjust the array sizes
> accordingly (`table.move()` is more complicated).

This makes sense, so that our 'varargs' object can have
t:insert(2,nil) and #t gets bumped up.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

Philipp Janda
In reply to this post by Dirk Laurie-2
Am 01.07.2016 um 07:51 schröbte Dirk Laurie:

> 2016-07-01 6:09 GMT+02:00 Philipp Janda <[hidden email]>:
>
>> Of course the `#` operator (and as a consequence the `table` functions)
>> should raise an error when applied to a non-array table without `__len` ...
>
> But breaking almost every existing Lua program just because its author
> was not clairvoyant would be going too far.
>
> The desired effect can be achieved by one function in the standard library.
> That's all.

Why does it have to be in the standard library? You can write reasonable
array implementations in Lua right now. Why does no one do it? I think
for the following reasons:

1.) The array literal syntax is built-in, convenient, and works good
enough (until it doesn't), so everybody uses it by default.
2.) The sequence handling in Lua does not raise an error if you pass
non-sequence tables. So even if you decide to use a custom array type in
your own code, you can't hand it out, because someone *will* use the `#`
operator or a table function on it, and things will silently go wrong.

Arrays without holes is actually a reasonable default choice for arrays
in Lua. Most of the time you don't need/want `nil`s in your array, and
the presence of a `nil` is actually a bug. The problem is that `#`
accepts such an array anyway. This is why I suggested `#` should raise
an error for non-array tables (and with the proposed subtype you can
check efficiently), and why I like the `.n` tables: you get told right
away when you passed an invalid table.

>
> Well, actually two, since the second one is useful for any OOP.
>
> ~~~~
> table.array(tbl[,n])
>
> Sets or modifies the metatable of tbl so that #t always equals n,
> __index points to the table library, and t:type() returns "array".
> If n is not supplied, it is calculated from the current tbl so that
> #tbl+1 is the first key absent from the table. Returns tbl.

This doesn't solve the problem if `#` and the table functions continue
to accept regular plain tables. Anyway, you'll still need to adapt
`table.insert()` and `table.remove()` to update the array length.


Philipp




Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

steve donovan
On Fri, Jul 1, 2016 at 9:20 AM, Philipp Janda <[hidden email]> wrote:
> Why does it have to be in the standard library? You can write reasonable
> array implementations in Lua right now. Why does no one do it? I think for
> the following reasons:

I'll add another reason - they're going  to be slower, since it needs
to call out to C and not just use VM opcodes.

But, this is still useful as a aide to debugging. Then switch to fast,
and bear C.A.R Hoare in mind that disabling assertions in a production
build is like going to sea without lifeboats ;)

Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

Philipp Janda
In reply to this post by steve donovan
Am 01.07.2016 um 09:04 schröbte steve donovan:
>
> Hence, make __index point to table. This code should behave exactly as
> Hisham expects:
>
> local t = table.pack(10,nil,'hello')
> foo(t:unpack())

I'm not sure what Hisham expects, but I think it would be awkward if the
OO syntax only worked on the arrays returned by `table.pack()` ...

>
> steve d.
>

Philipp



Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

steve donovan
On Fri, Jul 1, 2016 at 9:32 AM, Philipp Janda <[hidden email]> wrote:
> I'm not sure what Hisham expects, but I think it would be awkward if the OO
> syntax only worked on the arrays returned by `table.pack()` ...

I should reference these things better - Hisham already thought that
pack()/unpack() was symmetrical. And if someone of his experience
expects this, then yes, this is a issue.

True, suddenly the notation changes. Better to just allow that
metatable to control __len. Tables with method notation is another
discussion. But I hope we would agree that table.unpack(t) in this
case should do the correct thing.

Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

Philipp Janda
In reply to this post by steve donovan
Am 01.07.2016 um 09:26 schröbte steve donovan:
> On Fri, Jul 1, 2016 at 9:20 AM, Philipp Janda <[hidden email]> wrote:
>> Why does it have to be in the standard library? You can write reasonable
>> array implementations in Lua right now. Why does no one do it? I think for
>> the following reasons:
>
> I'll add another reason - they're going  to be slower, since it needs
> to call out to C and not just use VM opcodes.

Are you sure? At least some of the array implementations I can think of
don't need `__index`, so read access would be as fast as with regular
tables. `__len` might even be faster for larger arrays if you store the
length somewhere. You do need `__newindex` if you want to have
auto-resizing for your arrays, but since this could trigger a table
reallocation I'm not sure how much that will actually matter ...

And I haven't even profiled VM opcodes vs. C calls yet.

Philipp



Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

Peter Melnichenko-2
In reply to this post by Philipp Janda
On Fri, Jul 1, 2016 at 7:09 AM, Philipp Janda <[hidden email]> wrote:
> There are few smaller steps we can make:
>
> *  Solve the `pack()`/`unpack()` symmetry problem.
> *  Enhance the table library to allow non-sequence based array
> implementations by adding a library metamethod `__resize` or `__setsize`, so
> that `table.insert()` and `table.remove()` can adjust the array sizes
> accordingly (`table.move()` is more complicated).

Does the second point mean I'll have to check for the new metamethod and
call it whenever I modify array part of a table passed to me from outside?

-- Peter

Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

Philipp Janda
Am 01.07.2016 um 11:03 schröbte Peter Melnichenko:

> On Fri, Jul 1, 2016 at 7:09 AM, Philipp Janda <[hidden email]> wrote:
>> There are few smaller steps we can make:
>>
>> *  Solve the `pack()`/`unpack()` symmetry problem.
>> *  Enhance the table library to allow non-sequence based array
>> implementations by adding a library metamethod `__resize` or `__setsize`, so
>> that `table.insert()` and `table.remove()` can adjust the array sizes
>> accordingly (`table.move()` is more complicated).
>
> Does the second point mean I'll have to check for the new metamethod and
> call it whenever I modify array part of a table passed to me from outside?

If you add or remove elements from that table (without using
`table.insert()`/`table.remove()`) and you want to support non-sequence
arrays, then yes.  The main point however is that `table.insert()` and
`table.remove()` can work correctly for alternative array implementations.

>
> -- Peter
>

Philipp



Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

Dirk Laurie-2
In reply to this post by Philipp Janda
2016-07-01 9:20 GMT+02:00 Philipp Janda <[hidden email]>:
> Am 01.07.2016 um 07:51 schröbte Dirk Laurie:
>>
>> The desired effect can be achieved by one function in the standard
>> library.
>> That's all.
>
>
> Why does it have to be in the standard library? You can write reasonable
> array implementations in Lua right now.

True. Most of us have something of the kind already, differing
in interface details and with different names. I.e. the wheel is
being reinvented all the time. But that is not the main reason.

The "implementation details" are in fact of cardinal importance.
If the array is in fact kept entirely in the 'array' part, there is
bound to be an improvement in performance.

> This doesn't solve the problem if `#` and the table functions
> continue to accept regular plain tables.

There is no problem if the user obeys the rules.

The user chooses not to use the array option at his own peril.

We seem to have conflicting goals here. I want a fast array
implementation that does not need a calculation every time
I use #, does not need to resize an array except when I ask
it to by calling table.array myself, does not need to take into
account that an element may be in the has part.

What I think you want seems to have some law-enforcing
dimension to it that to my mind violates the spirit of Lua.

Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

Philipp Janda
Am 01.07.2016 um 11:37 schröbte Dirk Laurie:
> 2016-07-01 9:20 GMT+02:00 Philipp Janda <[hidden email]>:
>
> The "implementation details" are in fact of cardinal importance.
> If the array is in fact kept entirely in the 'array' part, there is
> bound to be an improvement in performance.

Have you encountered a case where the array is *not* kept entirely in
the 'array' part? This is not an easy thing to do without `nil`s. And if
you do have a sparse array, maybe you don't want to actually store all
those `nil`s.

In case you want to go looking: The getsize[1] module can tell you how
big array and hash part are, which in turn tells you where your integer
keys are stored ...

>
>> This doesn't solve the problem if `#` and the table functions
>> continue to accept regular plain tables.
>
> There is no problem if the user obeys the rules.

Then what do we have error messages and stack traces for? You won't need
them if the user always obeys the rules.

>
> The user chooses not to use the array option at his own peril.
>
> We seem to have conflicting goals here. I want a fast array
> implementation that does not need a calculation every time
> I use #, does not need to resize an array except when I ask
> it to by calling table.array myself, does not need to take into
> account that an element may be in the has part.
>
> What I think you want seems to have some law-enforcing
> dimension to it that to my mind violates the spirit of Lua.

I've found some other examples of violations of the spirit of Lua:

 > 1+"0"
1.0
 > 1+""
stdin:1: attempt to perform arithmetic on a string value
 > table.insert( {}, 1.3, true )
stdin:1: bad argument #2 to 'insert' (number has no integer representation)
 > table.insert( {}, 5, true )
stdin:1: bad argument #2 to 'insert' (position out of bounds)

If a function or operator only works correctly for a subset of the
possible input values, why shouldn't it inform the user when he/she is
making a mistake? And why would such kindness be a violation of the
spirit of Lua?


Philipp

   [1]: https://github.com/siffiejoe/lua-getsize



Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

Sean Conner
In reply to this post by Jonathan Goble
It was thus said that the Great Jonathan Goble once stated:
> A new type would have many advantages, chief among them elimination of
> the need to store the length as a field in the table or metatable
> (since the length would now be known and tracked by the C internals),
> and elimination of the question of how to set the initial length from
> a constructor (since array constructors probably wouldn't allow
> explicit keys/indices).

  There exist a few ways right now to construct a valid Lua sequence.  They
are:

        x = { 1 , 2 , 3 }
        x = { [1] = 1 , [2] = 2 , [3] = 3 } -- can be out of order
        x = {} x[1] = 1 -- can be out of order
                x[2] = 2
                x[3] = 3
        x = {} x[#x+1] = 1
                x[#x+1] = 2
                x[#x+1] = 3
        x = {} table.insert(x,1)
                table.insert(x,2)
                table.insert(x,3)

and I have existing code that uses all these methods (second one most often
when I'm constructing a table of anonymous functions, just to be explicit;
and in order---I'm not *that* crazy enough to define them out of order).

  Moving on, which ways should be supported, and which ones dropped?

  -spc (And I think that covers all the methods of making a sequence)

Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

Ross Berteig
On 7/1/2016 3:32 PM, Sean Conner wrote:
>   There exist a few ways right now to construct a valid Lua sequence.  They
> are:  ....
>
> x = {} x[#x+1] = 1
> x[#x+1] = 2
> x[#x+1] = 3

This is the one that I probably use casually the most often, usually to
assemble a large string from a bunch of computed bits and pieces which
are then passed to table.concat().

It is also the form that has not been mentioned in this long thread so far.

IMHO, a very useful property of # on a table t is that it identifies a
free slot named t[#t+1], whether t is a sequence or not. Proposals that
force # to be constant would clearly break that property.

Now if we get a new "sequence" type, making # be immutable might be
sane. A while back there was talk of making an n-tuple type which would
be immutable once constructed like strings are. If that type existed,
then ... would clearly be an instance of it.

IIRC, questions about what happens when an immutable ... is filled with
references to mutable objects and other headache inducing edge cases
became the enemy of the proposal and it went nowhere.

That said, a very simple fixed length array-like object would cover most
of the use cases that stem from handling of ... and similar lists that
can include gaps.

But it needs a name that helps reduce the user confusion. As does the
internal implementation detail of the table's "array part" which keeps
getting stirred into this discussion even though it has no place outside
of the implementation of a table. So don't call the new thing "Array"
unless you plan to take that bull by the horns.

--
Ross Berteig                               [hidden email]
Cheshire Engineering Corp.           http://www.CheshireEng.com/
+1 626 303 1602

Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

Dirk Laurie-2
In reply to this post by Philipp Janda
2016-07-01 13:21 GMT+02:00 Philipp Janda <[hidden email]>:

> Am 01.07.2016 um 11:37 schröbte Dirk Laurie:
>> 2016-07-01 9:20 GMT+02:00 Philipp Janda <[hidden email]>:
>>
>>> This doesn't solve the problem if `#` and the table functions
>>> continue to accept regular plain tables.
>>
>> There is no problem if the user obeys the rules.
>
>
> Then what do we have error messages and stack traces for?
> You won't need them if the user always obeys the rules.

This is a straw man argument. I have never suggested for one
moment that there should not be error messages and stack
traces.

>> The user chooses not to use the array option at his own peril.
>>
>> We seem to have conflicting goals here. I want a fast array
>> implementation that does not need a calculation every time
>> I use #, does not need to resize an array except when I ask
>> it to by calling table.array myself, does not need to take into
>> account that an element may be in the has part.
>>
>> What I think you want seems to have some law-enforcing
>> dimension to it that to my mind violates the spirit of Lua.
>
> I've found some other examples of violations of the spirit of Lua:

Another straw man argument. I did not say that there are no
existing violations of the spirit of Lua. I said that enforcing
laws is against the spirit of Lua. "Lua provides mechanisms,
not policies."

> If a function or operator only works correctly for a subset of the
> possible input values, why shouldn't it inform the user when
> he/she is making a mistake? And why would such kindness
> be a violation of the spirit of Lua?

Naturally the user would be informed of a mistake. But it is
not a mistake to use a table function in the way it has always
been done in Lua. In fact. that is still the only way to work
with arrays of variable length.

My proposal is that there should be a fixed-length array,
allowing implementors to optimize for speed. Of course
the semantics of array functions that at present are allowed
to adjust array size should be modified. table.remove can
never be an error, table.insert may be. Assignment to an
out-of-bounds element can easily be trapped: it's a
__newindex.

a=table.array{1,2,3,4}
a:remove(4) --> a is now {1,2,3,nil;}
a.insert{2,10} --> a is now {1,10,2,3};
a:insert(3,100) --> error message: non-nil element pushed off array
a[5]=20 --> error message: assignment beyond array length

Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

Philipp Janda
Am 03.07.2016 um 18:43 schröbte Dirk Laurie:

> 2016-07-01 13:21 GMT+02:00 Philipp Janda <[hidden email]>:
>> Am 01.07.2016 um 11:37 schröbte Dirk Laurie:
>>> 2016-07-01 9:20 GMT+02:00 Philipp Janda <[hidden email]>:
>>>
>>>> This doesn't solve the problem if `#` and the table functions
>>>> continue to accept regular plain tables.
>>>
>>> There is no problem if the user obeys the rules.
>>
>>
>> Then what do we have error messages and stack traces for?
>> You won't need them if the user always obeys the rules.
>
> This is a straw man argument. I have never suggested for one
> moment that there should not be error messages and stack
> traces.

The point was that you won't ever see error messages or stack traces if
you always obey the rules. So they must be superfluous, right? Unless
people, for some reason, don't always follow the rules, and then error
messages and stack traces become very useful ...

>>>
>>> What I think you want seems to have some law-enforcing
>>> dimension to it that to my mind violates the spirit of Lua.
>>
>> I've found some other examples of violations of the spirit of Lua:
>
> Another straw man argument. I did not say that there are no
> existing violations of the spirit of Lua. I said that enforcing
> laws is against the spirit of Lua. "Lua provides mechanisms,
> not policies."

I don't know where the spirit of Lua stops and where the practical
compromises start, but there are similar cases to the one proposed
(correct type, but invalid value), where Lua chooses to raise an error.
That certainly isn't the only option: I believe `1+""` is legal in
Javascript (or was it PHP?).

IIRC, the reason why Lua doesn't check for valid sequences is that it is
expensive to do. But if we change the way Lua represents arrays, we
could fix that -- unless we continue to support sequences as a fallback.

>
> Naturally the user would be informed of a mistake. But it is
> not a mistake to use a table function in the way it has always
> been done in Lua.

I think it boils down to the question whether passing a non-sequence to
a table function or the `#` operator is a mistake or not. Lua says it's
undefined, and I do see it as a mistake, YMMV.

> In fact. that is still the only way to work with arrays of variable
> length.

You lost me there. Most of the proposals in this thread are about
variable length arrays (including yours, actually). One of the
interesting questions is under which circumstances the length should change.

>
> My proposal is that there should be a fixed-length array,
> allowing implementors to optimize for speed.

I'm not sure you'll get much speed out of this. There's not much you can
do except represent the array data as a C style array, which Lua already
does. You'd probably be able to save some memory though.


Philipp




Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

Dirk Laurie-2
2016-07-04 10:55 GMT+02:00 Philipp Janda <[hidden email]>:
> Am 03.07.2016 um 18:43 schröbte Dirk Laurie:
>> My proposal is that there should be a fixed-length array,
>> allowing implementors to optimize for speed.
>
>
> I'm not sure you'll get much speed out of this. There's not much you can do
> except represent the array data as a C style array, which Lua already does.
> You'd probably be able to save some memory though.

I could continue the argument, but my heart is not really in it.
I usually wear the "I like Lua the way it is" T-shirt. Lobbying
for a new feature does not come naturally :-)

Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

Andrew Starks-2
On Mon, Jul 4, 2016 at 5:40 AM, Dirk Laurie <[hidden email]> wrote:

> 2016-07-04 10:55 GMT+02:00 Philipp Janda <[hidden email]>:
>> Am 03.07.2016 um 18:43 schröbte Dirk Laurie:
>>> My proposal is that there should be a fixed-length array,
>>> allowing implementors to optimize for speed.
>>
>>
>> I'm not sure you'll get much speed out of this. There's not much you can do
>> except represent the array data as a C style array, which Lua already does.
>> You'd probably be able to save some memory though.
>
> I could continue the argument, but my heart is not really in it.
> I usually wear the "I like Lua the way it is" T-shirt. Lobbying
> for a new feature does not come naturally :-)
>

I generally agree with this, on the basis that this is not being
brought forth in the face of a real problem. For example, nobody is
saying, "I can't get my game to work because the performance of my
array library is lacking..."

1: Lua has only tables for structures and all other structures built on those.
2: Ordinality and length are two features that are often required. (I
imagine that some would say "sequences", but I think it comes down to
these two properties) Both can be implemented in tables, but they
could be even more efficient, if more help were provided from Lua.
3: The existence of a length operator provides much of the fuel for
this debate. So does the {...} notation.

There have been times when *a* solution to a problem would have been
easier to implement if the integral keys were always returned in
order. I'm guessing that this would be disruptive, but I mention it
because it's my least favorite limitation of tables / sequences.

--
Andrew Starks

Reply | Threaded
Open this post in threaded view
|

Re: New array type? (was: 'table' as fallback for tables)

Hisham
In reply to this post by steve donovan
On 1 July 2016 at 04:37, steve donovan <[hidden email]> wrote:
> On Fri, Jul 1, 2016 at 9:32 AM, Philipp Janda <[hidden email]> wrote:
>> I'm not sure what Hisham expects, but I think it would be awkward if the OO
>> syntax only worked on the arrays returned by `table.pack()` ...
>
> I should reference these things better - Hisham already thought that
> pack()/unpack() was symmetrical. And if someone of his experience
> expects this, then yes, this is a issue.

My post here about this surprise was true, but also meant to be
illustrative, hoping to see if others would be caught off-guard as me.
For the record, after I posted it, I checked the code of the recent
module I wrote that had several uses of unpack(); in most of them the
tables I was unpacking would never contain nils; in some uses I was
setting the unpack limits explicitly, but in one of them the lack of
explicit limits was an actual bug.

Amusingly, I was told off-list by another Lua user (who's more
experienced than me) that after reading my post they went "oh-oh" and
double-checked their own code as well. :)

So if _that_ user thought that pack()/unpack() was symmetrical, then I
say yes, this is an issue. :)

-- Hisham

1234