... took out the tuple handling to simplify things. (Now that it’s [maybe] working I might take a stab at adding it back in, though I doubt I’d ever use it.)
Wait! Before you go digging any deeper, let's talk about the target semantics!
High level, one of the big warts on any compound assignment implementation is going to be the way it handles (or fails to handle) multi-value assignments. I've experimented with a couple different rules for multi-value compound assignments. And, with the benefit of hindsight, I'd say that the one I included in my 2013 power-patch implementation is actually one of the worst rules I've tried.
To review the semantics of that old patch, what I did was to make statements like this one legal:
a,b,c+=2,f()
Expanding them to something like:
do
local t1,t2=f()
a,b,c=a+2,b+t1,c+t2
end
I did that because it seemed like the natural "Lua-like" way of combining compound assignment with a multi-value assignment statement.
However, in the 6+ years since I added that rule to my parser, I've almost never used it. And when I have used it, I've often regretted doing so, as the implied code is hard to read in practice, and tends to encourage various kinds of bugs.
I have experimented with one other multi-value compound assignment rule, however, one that converts
a,b,c+=1
to
a,b,c=a+1,b+1,c+1
(or, in a more complex case)
a,b[d[i]],c+=f()
to
do
local t1=d[i]
local t2=f()
a,b[t1],c=a+t2,b[t1]+t2,c+t2
end
In my experience, that second rule is much more useful in practice, and it's far less bug or typo prone.
I'm not sure how difficult it would be to implement under 5.4.0-beta, but, if someone is going to code up an updated tuple-semantic for compound assignment, that's the one I'd recommend. My original semantics are really too complex for their own good. I think what you want, if anything, is a simpler semantic that dodges all the complexities that come up when you try to integrate compound assignments and open expressions.
Happy holidays,
-Sven
