What is the result value of a lua statement?

[kcl]

I've dug into the lua docs, but I'm not sure I'm clear on the 'value' of a statement, particularly one that returns multiple values. Three questions:

First, I'm pretty sure a statement can be tested for its value. That is, the statement 'if (a = b) ...' will set a to the value of b and then test the resulting a value for true or false. Correct?

Given that's the case, what about multiple values? If its like perl, although equates are right associative ('a = b = c' sets b to c and then sets a to b), the left side of an equate is left-associative, so the result value will be the "rightmost" equate. That is, 'if (a, b = x, y) ...' will set a to x, b to y, and then test the resulting b value for true/false. Is that true with lua, too?

Finally, if the above is true, by extension the statement 'if ((a, b, c) = fnctn(params)) ...' would test the truth value of the resulting c value returned by fnctn(). Right?

[Mark F]

Sorry, I don't know the answers to your questions. :( I believe you could find the answers by trial and error using the script editor, though.

I have a philisophical question for you. :) Why would you want to obscure the intention of your code by relying on a side effect like this?

What is the benefit of writing code like this:
'if (a = b) ...'
over this:
'a=b
if (a ~= 0) ...'

What is the benefit of writing code like this:
'if ((a, b, c) = fnctn(params)) ...'
over this:
'a, b, c = fnctn(params)
if (c ~= 0) ...'

2-3 years from now, when you or someone else needs to change it, which will be easier to understand and adapt?

Please don't take this as an attack. It is not meant to be one. I see code every day that is written this way and am continually trying to understand the benefit.

[kcl]

Mark -- No problem. I don't feel attacked at all. In fact, I think I'll do a little philosophical expounding myself. :D

Actually, in general I completely agree with you. I've been desiging, writing, and supporting code since the late 1960s. I highlited 'supporting' because you're right, in the long term the most important function of any block of code isn't what it does so much as how easy or difficult it will be to support. I've probably directly trained more than fifty programmers over the years and indirectly affected many more, in languages ranging from assembly to today's object-oriented systems, on everything from compilers to business applications. In addition to such things as "build debugging into your design", "comment the hell out of your code", and "has anyone else seen what you're doing?" (:wink:), I primarily try and get across how powerful the KISS principle is (Keep It Simple, Stupid), both in design and coding.

Its been my experience that programmers tend to go through three phases of how they do code design and development. They first start out creating simple and direct systems, because they're not that skilled yet in their profession or the language they're using. Then, as they become more and more skilled, particularly within their first language, they get to the second phase. They become infatuated with the language's nuances and side-effects, and as they try and make maximum use of these their code becomes obscure, intricate, and impossible to follow. (Its like the old APL (or was it PL1?) half-serious joke of trying to distill each routine down to one, totally unreadable line.) Finally, after they or others have beat their heads against a wall supporting this obscure code (and if they're smart), they get to the final phase; writing simple and direct systems again!. Its the primary reason support people prefer systems written by novices or the very skilled, but not the semi-skilled. (And, unfortunately, I often worry that the vast majority of the folks in my profession are in the semi-skilled category. Sigh.)

Going back to your orginal questions, this is all complicated by definition and degree. Specifically, who defines what is obscure, and at what level? For example, perhaps I've used too many languages where '=' is an expression operator, but I don't have a problem with simple equates within 'if', 'while', 'for' and the like, and this is particularly true for loop structures. In my opinion, something like 'while (x = get_next_item(a, b)) { <statements> }' is cleaner code than most other alternatives (equate prior to and at the end of the loop, exiting the loop manually (i.e., 'break'), etc.). Of course, you can overdo practically anything. I don't think any of us would like to see 'if (a = fnc1(b = c, d = fnc2(e = 4))) ...', for example.

I think the specific language characteristics need to be considered, too. If you're creating a class within an OO language, do you create a 'startup' method that must be called with initialization parameters, or bundle those parameters and functionality into the constructor. If you have a language like perl or lua that are designed to pass and return parameters via lists of by-value scalers, something like 'while ((a, b, c) = fnctn(x, y)) ...' is probably expected and makes sense, whereas a language like C where by-reference parameters are common you'd probably want code like 'while (fnctn(x, y, &a, &b, &c)) ...'.

I think the bottom line to all of this is that you need to take everything into account and ask this question: Will the code or design be confusing to support or understand in the future? If you think the answer might be 'yes', then you need to change it. Also note that this doesn't necessarily mean changing the code. Sometimes just adding descriptive comments or breaking a larger routine into smaller, understandable components will do the job.

Well, I think I've rambled on long enough. I'll get off my soapbox, now.

[Mark F]

THANK YOU! :D

Its like the old APL (or was it PL1?) half-serious joke of trying to distill each routine down to one, totally unreadable line.
It was APL and it wasn't a joke. :) There was an international association that held a yearly competition for the "best" one-line program. One of my former colleagues was very proud of the fact that one of his entries got an honorable mention. The problem was his C code looked the same. :o


I think the bottom line to all of this is that you need to take everything into account and ask this question: Will the code or design be confusing to support or understand in the future?
This was the reason for my question. We might just disagree (a bit) on what may be "confusing".

I've never been part of a project where the comments consistently match the code after the second point release. So, for me, commenting the tricky parts is not sufficient. How have you been able to force or enforce this simple concept on projects with 50+ programmers?

Over the past 6 years, the pool of available programming talent has been limited forcing many to hire folks who don't fit the job perfectly. Trying to use nuances of a prgramming language they are learning on the job is not a pretty sight. While someone with training or experience with a particular language would understand 'while ((a, b, c) = fnctn(x, y)) ...', using a simpler, brute force construct, while not as elegant, tends to be understood by more language novices, in my experience.

And now even more of my ramblings :) ...

In responding to your original question, I was concerned you might be preparing to endorse the "semi-skilled" trap. For many on this forum, this is their first encounter with programming, much less LUA. I try to help out here in my spare time. From this perspective, I thought questioning what I considered "hard to support" programming practices might reduce questions and frustration in the future.

I made a few too many assumptions. Sorry. :(

By the way, I still don't know the answer to your original questions. If no one here can answer, there is a LUA language list on Yahoo and there is always www.lua.org Best of luck.