Rearange documentation prioritizing more useful stuff higher

[Indieberrie]

I was kinda confused first time reading this when I figured out how to run test, but still had no clue how to run compiler itself.
I guess it makes more sense that tests are at the bottom, while description of project and setting up should be higher (even than supported features)

[Lonami]

P.S. super happy to see you're this engaged with this little project ;)

[Indieberrie]

You said it just as I was thinking about doing something else, since I have a lot of stuff on my schedule (instead of no lifing mindustry)
I'll probably contribute much more (not having arrays (lists?) is going on my nerves), but I have no clue when will that be
Thanks for the great tool!

[Lonami]

not having arrays (lists?) is going on my nerves

Those are tricky because they're no longer a "simple value" which is held in a single variable.

While for x in [a, b, c]: could be special-cased to run the loop body with x going through all of a, b, c, things get more difficult if you were to support to assign the list to a variable, which can then be moved around, passed as parameters, iterated over, etc. Because the type would have to be tracked to properly work on that variable (e.g. in x = y, the assignment would be very different for lists and simple values).

Unless… perhaps "list" variables point to their length, and when used as a list, they "just" work. Imagine

x = [1, 2, 3]
for y in x:
  print(y)

Could generate (pseudo)

x = 3
x__list0 = 1
x__list1 = 2
x__list2 = 3
set loopcounter 0
:loop
jmp loopcounter == 3 to :exitloop
set y x__list{loopcounter}
print y
printflush
jmp :loop
:exitloop

Yeah that's some nice food for thought.

[Lonami]

(Now as for what would happen if you had x = 3; for y in x, well, it would do the same, but it would pick out null every time, kinda "undefined behaviour".)

[Indieberrie]

Have you thought about using heap to allocate arrays?
Allocating arrays on the stack (or using infinite registers) is only good when the array size is known at compile time.
As I see, whole idea of python arrays (I use array and list interchangably) is that they are all runtime resizable which means implementing them on stack is a bad idea

[Lonami]

The heap (memory cells) can only store numbers (so, no strings, or @variables):

set result "hello"
write result cell1 0
read result cell1 0
print result
printflush message1

This prints 1. Removing the read does print "hello".

It's true, as you point out, infinite variables would not work with dynamic array sizes (since there's no way to refer to a dynamic variable name in mlog).

However, tuples are immutable, so the fixed size makes more sense. Maybe lists could only support numbers (implemented via Mem), and tuples would support anything (implemented via infinite registers). But what memory cell would be used for the list?

foo = [1, 2, 3] @ cell1

could be made work. Ah, so many ideas!

[Lonami]

Let's move this discussion to the separate issue linked above if you have further comments.