lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


I suspect that relaxing this rule would not make the parser much
slower; the simplicity of Lua is intended to help the _human_ parsing
the code. E.g. the famous C/C++ mistake 'if (a = b)' is not possible.
Code is easier to read when there aren't too many possible surprises.

Lets says speed was not much of an issue, then what modifications would be needed to have assignment as an operator in tables.

So if there is say, an __assign() meta-function present in a table, then that is called with the value being assigned.

Also C++ allows references on the left hand side of an assignment statement. So a function which returns a reference can have a value assigned to the returned variable.

If this were present in Lua then having an assignment to the result of a function call would be really easy. Since tables are passed by reference, a function could return the table. Then the assignment operator could be invoked on it.

local tbl = {}
tbl.value = 0

mt = { __assign(value) = function(value) tbl.value = value end}
setmetatable(tbl, mt)

function foo(tbl)
    return tbl
end

foo(tbl) = 2

-- tbl.value = 2 now


On Fri, Dec 25, 2015 at 1:24 PM, steve donovan <steve.j.donovan@gmail.com> wrote:
On Thu, Dec 24, 2015 at 10:04 PM, Duncan Cross <duncan.cross@gmail.com> wrote:
> languages. My understanding is that keeping this strict division
> between _expression_ and statement is part of the simplicity that Lua
> needs to keep its parser as fast as possible.

I suspect that relaxing this rule would not make the parser much
slower; the simplicity of Lua is intended to help the _human_ parsing
the code. E.g. the famous C/C++ mistake 'if (a = b)' is not possible.
Code is easier to read when there aren't too many possible surprises.