Lua operators, why isn't +=, -= and so on defined?

问题

This is a question I've been mildly irritated about for some time and just never got around to search the answer to.

However I thought I might at least ask the question and perhaps someone can explain.

Basically many languages I've worked in utilize syntactic sugar to write (using syntax from C++):

int main() {
    int a = 2;
    a += 3; // a=a+3
}

while in lua the += is not defined, so I would have to write a=a+3, which again is all about syntactical sugar. when using a more "meaningful" variable name such as: bleed_damage_over_time or something it starts getting tedious to write:

bleed_damage_over_time = bleed_damage_over_time + added_bleed_damage_over_time 

instead of:

bleed_damage_over_time += added_bleed_damage_over_time

So I would like to know not how to solve this if you don't have a nice solution, in that case I would of course be interested in hearing it; but rather why lua doesn't implement this syntactical sugar.

回答1:

This is just guesswork on my part, but:

1. It's hard to implement this in a single-pass compiler

Lua's bytecode compiler is implemented as a single-pass recursive descent parser that immediately generates code. It does not parse to a separate AST structure and then in a second pass convert that to bytecode.

This forces some limitations on the grammar and semantics. In particular, anything that requires arbitrary lookahead or forward references is really hard to support in this model. This means assignments are already hard to parse. Given something like:

foo.bar.baz = "value"

When you're parsing foo.bar.baz, you don't realize you're actually parsing an assignment until you hit the = after you've already parsed and generated code for that. Lua's compiler has a good bit of complexity just for handling assignments because of this.

Supporting self-assignment would make that even harder. Something like:

foo.bar.baz += "value"

Needs to get translated to:

foo.bar.baz = foo.bar.baz + "value"

But at the point that the compiler hits the =, it's already forgotten about foo.bar.baz. It's possible, but not easy.

2. It may not play nice with the grammar

Lua doesn't actually have any statement or line separators in the grammar. Whitespace is ignored and there are no mandatory semicolons. You can do:

io.write("one")
io.write("two")

Or:

io.write("one") io.write("two")

And Lua is equally happy with both. Keeping a grammar like that unambiguous is tricky. I'm not sure, but self-assignment operators may make that harder.

3. It doesn't play nice with multiple assignment

Lua supports multiple assignment, like:

a, b, c = someFnThatReturnsThreeValues()

It's not even clear to me what it would mean if you tried to do:

a, b, c += someFnThatReturnsThreeValues()

You could limit self-assignment operators to single assignment, but then you've just added a weird corner case people have to know about.

With all of this, it's not at all clear that self-assignment operators are useful enough to be worth dealing with the above issues.

回答2:

I think you could just rewrite this question as

Why doesn't <languageX> have <featureY> from <languageZ>?

Typically it's a trade-off that the language designers make based on their vision of what the language is intended for, and their goals.

In Lua's case, the language is intended to be an embedded scripting language, so any changes that make the language more complex or potentially make the compiler/runtime even slightly larger or slower may go against this objective.

If you implement each and every tiny feature, you can end up with a 'kitchen sink' language: ADA, anyone?

And as you say, it's just syntactic sugar.

回答3:

Another reason why Lua doesn't have self-assignment operators is that table access can be overloaded with metatables to have arbitrary side effects. For self assignment you would need to choose to desugar

foo.bar.baz += 2

into

foo.bar.baz = foo.bar.baz + 2

or into

local tmp = foo.bar
tmp.baz = tmp.baz + 2

The first version runs the __index metamethod for foo twice, while the second one does so only once. Not including self-assignment in the language and forcing you to be explicit helps avoid this ambiguity.

来源：https://stackoverflow.com/questions/20091779/lua-operators-why-isnt-and-so-on-defined