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

[Francisco Olarte <folarte@...>]

On Fri, Nov 1, 2019 at 6:24 PM bil til <flyer31@googlemail.com> wrote:
> @Francisco:
> But these tables you cite here have NO indexed / list part.

Yes they do, it just happens to be empty.

> (as they do NOT start at 1).

> So for your tables print(#t) gives zero ... they are
> "hash only" tables ...

> ... I want only a clear statement about the indexed /
> list part of the tables ... if a table has NO indexed part,
> then it is ok for me, that the order will be "accidential".

What you are not accounting for is that, after a few manipulations, a
table might end with some unexpected values in the hash part. Lua
tables are just dictionaries with an optimization for small ( defined
as "starting at 1 in this case") integer indexes. They also overload
the # operator to work correctly in sequences, but that is all. If you
want to enumerate in your way, just define your datatype and you'll be
right. Do something like rereserving the fields __I__MIN,  __I__MAX in
the hash part and enumerate with them. Hide them if you want using any
of the many tricks there are.

....... ( to @roberto)
> But you have to admit, that this is a "somehow
> bizarre" constructor, using a constructor which
> lists the indexed items "at the end".
> If you do it in a "more normal way", also possibly
> the hashed key first, but then the indexed table
> in a separate command, then all fine:

Those statements of yours sound like "do my homework". Translated as
"instead of coding my problem in <insert language name here> lets rant
about how the language is bad and should include the magic
"solve_bil_til_problem_xxxx" instruction. I'm not accusing, just
pointing the impression it gives me.

Also, if you persist on sending those long messages, a little bit of
properly quoted context would help a lot with the understanding.

Francisco Olarte.