> Unfortunately, it ("for k,v in t do ..." syntax) simultaneously obscures the function of the code.
I do not understand what you mean- could you elaborate on this?
Basically, while I also don't like the proliferation of "in pairs(...)" boilerplate, I have problems with the details of John's approach. Vanilla Lua's generic for syntax is already pretty complex, and�under the self iterating objects patch the
� for <vars> in <explist> do
syntax gets�significantly�more complicated, because there's a switch on the type of the first result of <explist>.�
Consider:
� for k,v in t do
The programmer may think that this is simply code for walking through the table -- but the truth is that it's something considerably more complex, as t can legally be either a table or function iterator, and which way it's interpreted depends on it's raw type. �In the case that t is a table, there's 2 different metatable lookups that will impact the result (__iter and __pairs).
If all we really want is to reduce boilerplate pairs() calls, there's no need to hack the VM. �It's sufficient to just add a new transformation rule to the parser.
-Sven
PS: I'm still agonizing over candidate table iteration syntax. �At this point, I think my favorite is:
for k,v == t do�
but it appears that
for k,v = t do
would also work, as we could intercept the numeric for logic in the case that there's no stated upper limit.
