I have reworked the article. I changed my categories, just like you wanted (because I agree with you) and I give more alternatives to pointers instead of relying on them.
>Something to mimic struct inheritance and other stuff (Casting)
Still not really sure what you're hoping for, there. Seems like an odd thing to request.
Everyone that thinks pointers are inheritely unsafe should shut up. They are as unsafe as the more abstract Java/C# reference. However they are usually implemented in an unsafe way. For example, Blizzard allowed them to reference stack variables, and instead of solving the problem using one of my solutions in this thread (which would be some work), they simply removed them. Blizzard could also implement Java like references, but that would be even more work, result in less power, and also require them to implement dynamic memory allocation.
For the petition/suggestions, you should add references (pointers or Java like references) to chapter 2.
Section 2.1 should include 2.5, as that is an obvious side effect.
Section 2.2 should only apply if they implement references or stick with pointers and remove taking the address of local variables. If they do the latter and implement dynamic memory allocation, we can implement this ourselves.
Section 2.3 should be removed altogether as we can already do this without or with pointers. With Java like references (and pointers, in a poor VM) there would be some minor overhead, but not nearly enough to warrant this ugly design choice.
Section 1.1 should probably add some hints to a solution. Instead of the opcodes referencing memory directly, they should simply refer to symbols (chapter 7 of this document shows how this can be done for a register based virtual machine).
There is also some things that you don't address that I did in my thread like:
- referencing a struct before it's defined (this isn't needed without references),
- fixed point arithmetics,
- associative arrays (this isn't needed without references),
- opcode limit,
- performance,
- closures (the current API seems to reduce the need for native closures, but they would still be very useful for different systems).
Since you seem to structure things after importance, you could also address some minor things like:
- the required curly brackets on blocks,
- the weird logic for conditionals (accepts ints, bools, colors and nullable types) and the logical not operator (accepts ints, bools and handles),
- the char type and char literals ('g') which doesn't seem to be used for anything,
- bulk copying.
I'm on a page about incorrect corrections, and spent the better part of like two hours trying to get someone to understand that -5^2 = -25, not 25, and then that post had comments get reposted because that group is self sustaining, and that person was in turn trying to explain what I just explained to them. And I'm taking that as a victory
I will be AFK for a couple of days you guys hold down the fort while I am gone. I will be checking in on my phone but that will severly limit me. Be back saturday!