Re: Why no for table-iterator like e. g. "hashpairs"?

[Philippe Verdy <verdy_p@...>]

It just proves that Lua, when it defined tables to be working both as
associative array (hashed dictionnary) and as indexed arrays (vectors,
i.e. "sequences" in Lua terminology) chose the wrong implementation
approach.

For now, the #t operator is completely broken. Tables have to be
segregated in applications between those used as integer-indexed
sequences (almost only data), and those using hashed dictionnaries
(notably all objects for their properties).

Something is severely wrong in Lua, compared to what Javascript and
PHP do, with similar constraints: the underlying implementation of
tables should NEVER affect what #t returns, and the API was not
consistantly written. The result in applications is unpredictable (and
why tables in Lua are so slow and memory-inefficient compared to
Javascript or PHP, even without their modern JIT compilers like v8 for
Javascript or Zend for PHP, or modern implementations of Perl or
Python?)

Tables are so universally used in Lua that this part should be
urgently refactored for efficiency, stability, and predictability.
Without it, Lua will remain a "toy", used in niche projects, it will
not compete in the same playground: Python rocks! Javascript rocks
too! Lua does not. Various projects that initially started with Lua
integration have renounced and disabled this feature and prefered
using other scripting engines (most frequently now they use
Javascript/ECMAscript, often though node.js and jQuery).

May be one way to revive Lua would be to have an implementation in
Javascript (I'm sure it will perform better and more safely than the
current implementation in C/C++, and Javascript engines are now much
easier to integrate and offer better integration with many more
libraries, including with other languages like Python, Perl, SQL,
PHP)...

Is there some stable port of Lua in Javascript (excluding external
LuaC: the standard library of Lua can perfectly be written in
Javascript with its own standard libary) that we could recommend ? or
in PHP ? or in Java (for server-side integration, including in
database engines, GIS applications, UI frameworks like the Android
SDK, the iOS SDK, or the Windows UWP, or UX components for Mozilla
browsers ?).

As well the default implementation in LuaC still has lot of progresses
to do for its memory manager and the garbage collector, as well in
terms of security (Lua VMs are easily broken by malicious scripts that
can crash it and crash all other competing threads, it's not safe for
use in multi-user contexts, as its memory usage is out of control: all
that is proposed is to create many separate instances of the Lua VM,
but this is also very inefficient and requires big servers with lot of
memory to serve many people; the instanciation of a new VM is much too
slow and CPU-intensive).


2019-11-04 13:30 UTC+01:00, nobody <nobody+lua-list@afra-berlin.de>:
> On 01/11/2019 09.55, bil til wrote:
>> I assume quite often a very long listed/indexed table might have
>> additionally some further key-value pairs with "hash-keys". E. g. a
>> polyline/xy-curve with very many points might additionally have a
>> name field and maybe some further info fields.
>>
>> If I want to iterate over such "further info fields" in a fast way in
>> lua (and I do NOT know the key names, or I possibly would like to
>> check such "further key names"), do I really have to iterate over the
>> complete table with pairs? (is this not a complete waste of time, as
>> I then possibly get also all the ipairs entries of the table for
>> iteration in my for loop?).
>
> If you want to iterate over different collections of fields, use
> multiple tables and put the <LOTS of stuff that you only want SOMETIMES>
> into a separate table.  Then you can iterate quickly over either the
> list or the extra fields.  E.g.:
>
>    curve = { { 23, 42 }, { 21, 37 }, metadata = { input = "mouse" } }
>
> [ipairs gets you just the list, pairs on .metadata is the other fields]
>
> or
>
>    curve = { input = "mouse", data = { { 23, 42 }, { 21, 37 }, … }, … }
>
> [tradeoff: different order, there's ONLY data in .data, but you'll have
> to manually skip .data when doing pairs() on the outer container.]
>
> or maybe even
>
>    curve = { input = "mouse", x = { 23, 21, … }, y = { 42, 37, … }, … }
>
> [split/"planar" representation tends to save A LOT of memory, if your
> code can handle it]
>
> (See also http://lua-users.org/lists/lua-l/2016-08/msg00256.html for
> some more bad ideas.)
>
> -- nobody
>
>