Re: bug report: LUA compiler glitch

[Lorenzo Donati <lorenzodonatibz@...>]

On 10/08/2011 2.14, Steve Litt wrote:
> On Tuesday, August 09, 2011 06:22:27 PM Lars Doelle wrote:
[...]
> Can anyone explain the benefit of:
>
> a, b = 1, 2
>
> The only place I've seen the slightest benefit of that was when
> capturing the return of functions returning multiple values.

Well, from my POV, beside capturing multiple returns [1], it is another 
possibility to aid readability (so I'm reinforcing what Dirk said), if 
used with a grain of salt.

More specifically, you can adapt the way you format your code *to the 
specific context* [2] to make it more readable, hence more maintainable.

For example, if two values are really related, it *may* be more readable 
to initialize them together:

local x, y, z = 0, 0, 0
local d = sqrt( x^2 + y^2 + z^2 )

*may* be better than (YMMV)

local x = 0
local y = 0
local z = 0
local d = sqrt( x^2 + y^2 + z^2 )

Of course this aspect is intermingled with good a choice of variables 
names (more an art than a science, according to somebody).

again, to expand on what Malkia said, it *may* be useful in one liners:

if some_condition1 then
  ret, err = nil, "AARGH!"
elseif some_condition2 then
  ret, err = nil, "SIGH!"
end
...
return ret, err

*may* be better than

if some_condition1 then
  ret = nil
  err = "AARGH!"
elseif some_condition2 then
  ret = nil
  err = "SIGH!"
end
...
return ret, err

I reinstate: it allows more freedom in how you write your code. As 
always, and in Lua especially, more freedom means also more freedom to 
shoot yourself in the foot! :-) As usual, power comes at the price of 
responsibility!


[1] BTW, capturing multiple returns is not an irrelevant aspect. Without 
multiple assignment multiple returns would really awkward to work with, 
at least with the current syntax (always using tables, e.g. {f()}, to 
capture multiple returns would be very inefficient) . This alone would 
justify this facility (unless one wanted to forfeit multiple returns 
altogether).

[2] There is an old refrain about choosing a coding style and stick to 
it to ease maintainability. I agree but to a point: coding style, even 
in the same programming language, should be context dependent. Like in 
natural language, when the intent is communication, you should choose 
the best "linguistic register" for the situation at hand (probably you 
wouldn't  want to speak the same "style" of english in a pub as when you 
are talking to a computer scientist workshop (unless you summoned a Lua 
user group in a pub :-D ). When I write a program whose context is 
"math", I use a different style, in order for the code to show better 
"the math beneath"; and the style is different when I write some text 
processing tool. Lua is great for this - even its free format is very 
dynamic! Try to do that in Java! :-)


> SteveT
>



-- Lorenzo