To your last question: By in order traversing the tree. This gives you the correct representing key list.
But it would make any efficient data structure (which list isn't in most cases) pointless if it was a list.
There are other collections missing beside Map and List: TStream and TBank to name the most important one.
And I highly disagree on the 1.26 mode switches. Hell we already have compatibility mode for stone age blitz (by not using strict at all), with this addition I would start feeling like BM was the worst prethought language ever if it needs 3+ different running modes to work somewhere usefull.
BM needs to become consistent, not even more trashed by another different operation mode. (to me, even the stone age blitz behavior in non strict should be removed, ie local are local to scope, ALWAYS and the like. There is no reason to support stone age blitz because for that stone age blitz already exists, right? :))
People that do not want to have new features are always free not to upgrade to the newest version as it is with any language (ever tried C++ GCC 3.4 to 4.0+? )
With this behavior *updating the language and writing a list with actual changes to the language etc*, we at least would have the chance to see current gen compiles for C++ end on Linux and Windows, where we are several years back and thus cut in optimations (the windows version is that old that it does not even know the Pentium3 flag so not even SSE support, just MMX ...)
This naturally would mean that Compiler updates and regular modul updates would need to be split. Currently this done through sync mod, but it was mentioned that there are problems and this might be dropped.
Compiler updates then could be of 2 simple types: sub minor *Bugfix* updates (like 1.2.2 to 1.2.4) where it only fixes things or minor *Upgrade* (1.2 to 1.3) where the feature set actually changes or behavior is different.
But it would make any efficient data structure (which list isn't in most cases) pointless if it was a list.
There are other collections missing beside Map and List: TStream and TBank to name the most important one.
And I highly disagree on the 1.26 mode switches. Hell we already have compatibility mode for stone age blitz (by not using strict at all), with this addition I would start feeling like BM was the worst prethought language ever if it needs 3+ different running modes to work somewhere usefull.
BM needs to become consistent, not even more trashed by another different operation mode. (to me, even the stone age blitz behavior in non strict should be removed, ie local are local to scope, ALWAYS and the like. There is no reason to support stone age blitz because for that stone age blitz already exists, right? :))
People that do not want to have new features are always free not to upgrade to the newest version as it is with any language (ever tried C++ GCC 3.4 to 4.0+? )
With this behavior *updating the language and writing a list with actual changes to the language etc*, we at least would have the chance to see current gen compiles for C++ end on Linux and Windows, where we are several years back and thus cut in optimations (the windows version is that old that it does not even know the Pentium3 flag so not even SSE support, just MMX ...)
This naturally would mean that Compiler updates and regular modul updates would need to be split. Currently this done through sync mod, but it was mentioned that there are problems and this might be dropped.
Compiler updates then could be of 2 simple types: sub minor *Bugfix* updates (like 1.2.2 to 1.2.4) where it only fixes things or minor *Upgrade* (1.2 to 1.3) where the feature set actually changes or behavior is different.