Question: value of multi-statement expression?

[sirksel]

Lexikos, as v2 development continues, can I rely on the behavior that a multi-expression in a return statement will continue to be allowed (although I know it doesn't return multiple values) and will always return the final sub-expression as the return value? I know it might be bad form, but in short utility functions, sometimes it's nice/quick to set the byrefs on a single line on the way out...

For example, in the following code, can I rely on the fact that answer will always be assigned false?

Code: Select all

example(byref x, byref y, byref z) {
    return x:=1,  y:=2,  z:=3,  false
}
answer := example(x,y,z)    ; answer is 0/false
MsgBox % x '`n' y '`n' z '`n' answer

I wasn't sure because I didn't see that this specific behavior was guaranteed in the documentation. Maybe I didn't look hard enough, but I don't think I read it in the "Return" or "Operators in Expressions" or "Returning Values to Caller" help sections. Thanks again for the assistance!

EDIT: To try to answer my own question, it occurred to me to try the more general case: answer := (x:=1, y:=2), which verified my assumption that answer is in fact assigned 2. I think it works because of the left-to-right evaluation of the multi-statement, such that a multi-statement expression, when used as part of a larger expression, evaluates to the value of its last sub-expression. I might have missed it somewhere, but I didn't see this general principle specifically documented anywhere, so now I've got myself wondering if that behavior also can be relied upon as v2 progresses?

[lexikos]

Did you try http://lexikos.github.io/v2/docs/Variables.htm ?

Behaviour is only guaranteed for the current alpha. That's why it still has the alpha label.

v1 uses the value of the first sub-expression, and some users like to use it to execute an expression (e.g. cleanup code) "after returning". Initially I changed it for two reasons:

1. Several languages I'm familiar with use the last sub-expression. I'm not aware of any using the first. It seems more intuitive to me, although I think some users perceive the return statement as binding to the leftmost sub-expression.

2. Comments in the source code indicated that the v1 implementation was chosen because the developer thought it was the only way possible. He was wrong - it is even easier to return the last sub-expression.

...But I might decide there isn't enough overall benefit to justify the change.

[sirksel]

Lexikos, thanks so much for the quick and very helpful answer. I'm embarrassed to say that all this time I've only been reading:
https://autohotkey.com/v2/v2-changes.htm
as a supersessor to just the regular v1 chm... and thinking that the two together gave me a complete picture of the latest with v2. Boy, was I wrong! Thanks for reminding me that this documentation exists. I will be doing more reading tonight, to make sure my not-so-complete picture is actually complete with your latest and greatest thoughts.

For what it's worth (maybe not much), I like the choice you've made to bind return to the last sub-expression. It seems more intuitive to me too. I like to use it in short functions that set byrefs as well as returning a value -- especially when the ultimate return value depends on something derived from one of the byref sets. I know I could guarantee the execution order by putting the byref sets in a line above, but somehow (especially for short functions), I really like seeing the final byref sets and the ultimate return in that final line.

Related to this, I was wondering if you have time to answer two quick follow-ups...

1. Python-style tuple unpacking. Because this is a language designed for non-programmers, I'm guessing that there will never be a sufficient use-case for Python-like tuple unpacking for multi-assignments and/or multi-returns, correct? There are often times when it would be nice to have x, y := getpoint(inputs) or r, g, b := getcolors(inputs) (where the return value of said functions is a simple array) without having to explicitly use/unpack an object. As you've reminded us in the past, nice-to-have/useful isn't always enough to justify the work and/or complication to the language -- and I'm guessing that's the case here, right? I'm also guessing that because AHK allows assignments within expressions (which Python doesn't), it would make parsing those statements significantly more challenging for the interpreter.

2. Custom iterators with >2 byrefs. Ever since you turned me on to customizing iterators with your Fibonacci example, I've tried to customize/rework the iterators of my most-used objects to be more intuitive. Would it be overcomplicating the language or difficult to extend the for k,v in obj syntax to optionally allow more than two vars, assuming a custom enumerator exists wtih the next(byref v1, byref v2, byref v3) defining more than two byref params? For example, it would be very convenient and very readable to be able to do:

Code: Select all

for red, green, blue in colors
for street, city, state, zip in addresses
for pos, len, val in custom_matches
...

It seems like the functionality is close to that today. I think you can have multiple byrefs in next(), but you can't use the for...in syntax to access anything beyond two of them. Correct? Do you feel like extending to more than two vars overcomplicates things or wouldn't be worth the implementation work?

Thanks again for all the help and all the work you do to make AHK such a great language!

[lexikos]

[...] I've only been reading:
https://autohotkey.com/v2/v2-changes.htm
as a supersessor to just the regular v1 chm... and thinking that the two together gave me a complete picture of the latest with v2. Boy, was I wrong!

No, you were mistaken.

v2-changes is intended to contain all non-superficial changes between v1 and v2. Search for "multi-statement". It is above the first paragraph containing "comma".

v2-changes also contains some changes related to topics that were never covered by the full documentation.

1. Python-style tuple unpacking.

All sorts of fancy syntax becomes feasible when you have a properly designed parser. We don't have that, yet. One of my side-projects is a script library for generic parsing, intended for use use implementing syntax experiments, analysis and conversion tools, etc. I've been working on it (or previous iterations of the project) on and off for several years.

2. Custom iterators with >2 byrefs.

This is feasible.

I think you can have multiple byrefs in next(),

Next() is just a method like any other. You can do whatever you want if you're calling it directly, but obviously, for..in in current versions will only ever pass one or two parameters.

[iseahound]

v2-beta
In case anyone was wondering how to write a multi-value return statement with the same functionality as v1:

Return the first value

Code: Select all

return ((a,*)=>a)(1, 2, 3) ; returns 1

Return the last value
This is the functionality sirksel was trying to maintain but it was changed.

Code: Select all

return (1, 2, 3) ; returns 3

Return any value from the beginning

Code: Select all

return ((a*) => a[2])(1, 2, 3) ; returns 2

Return any value from the end

Code: Select all

return ((a*) => a[-3])(1, 2, 3) ; returns 1

[20170201225639]

Return the last value
This is the functionality sirksel was trying to maintain but it was changed.

Wait, I thought your first 2 examples show it was kept after all? That in v2, it is the value of the last expression that's returned, not (as in v1) that of the first?

Relatedly, if that's the v2 behavior with respect to return, what happens now with code like this?

Code: Select all

Loop 10
{
    Loop 10, OuterAIndex:=A_Index
    {
        MultiplicationTbl[OuterAIndex][A_Index] := OuterAIndex * A_Index
    }
}

[iseahound]

I do not understand your post. The current effect of running

Code: Select all

return 1, 2, 3

throws an error.

[20170201225639]

I do not understand your post. The current effect of running

Code: Select all

return 1, 2, 3

throws an error.

Oh I see, you were talking about the 1st bolded part of the quote below, which was changed between early alpha and current beta. I was talking about the 2nd bold part, which was kept

the behavior that a multi-expression in a return statement will continue to be allowed (although I know it doesn't return multiple values) and will always return the final sub-expression as the return value?

In v1,

Code: Select all

for k, v in (x, y, z)

calls x's enumerator, in v2, it calls z's

[lexikos]

Wouldn't it have been quicker to run the code and find out?

Code: Select all

 Loop 10, OuterAIndex:=A_Index

is invalid, and has always been invalid.

[20170201225639]

Wouldn't it have been quicker to run the code and find out?

Code: Select all

 Loop 10, OuterAIndex:=A_Index

is invalid, and has always been invalid.

you're right. That was invalid even in v1. My bad.