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

[Dirk Laurie <dirk.laurie@...>]

2016-07-01 13:21 GMT+02:00 Philipp Janda <siffiejoe@gmx.net>:
> Am 01.07.2016 um 11:37 schröbte Dirk Laurie:
>> 2016-07-01 9:20 GMT+02:00 Philipp Janda <siffiejoe@gmx.net>:
>>
>>> 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