Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Passing variables w/assignments to ByRef function parameters


  • Please log in to reply
23 replies to this topic
Laszlo
  • Moderators
  • 4713 posts
  • Last active: Mar 31 2012 03:17 AM
  • Joined: 14 Feb 2005
There is a remarkable exception:

Comma (multi-statement) [v1.0.46+]. Commas may be used to write multiple sub-expressions on a single line... Such statements are executed in order from left to right.

That is, the comma is the only operator, where the execution order is known. (Note the difference: in a+b+c the order of the additions is also specified to be from left to right, but it only means that a+b+c = (a+B)+c. It is left unspecified in which order the sub-expressions a, b and c are evaluated, what prohibits the use of conflicting side effects, like x++ or function calls with ByRef parameters.)

jonny
  • Members
  • 2951 posts
  • Last active: Feb 24 2008 04:22 AM
  • Joined: 13 Nov 2004
Remember, we also have a wiki. You could post as many obscure technical details as you want there, and reference that for the few times it's needed.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Above the operator table, the docs also state, "Operators of equal precedence such as multiply (*) and divide (/) are evaluated in left-to-right order unless otherwise specified below."

Does anyone know if other languages guaranty left-to-right evalution order in an expression like func1() + func2()? I spent about an hour searching but couldn't find anything definitive in places like Wikipedia, php.net, or even a general search.

If I guaranty it in the help file, it will be necessary to abide by it in all future releases, which might reduce performance and flexibility. I'd prefer to go along with what other languages do; so if most of them don't guaranty evaluation order, the same can be stated somewhere in the help file.

By the way, the left side of a ternary like ++x>1 ? x : y is evaluted completely before choosing the winning branch. However, this seems too implicit to document, not to mention the rarity of such expressions.

Thanks.

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004

I don't know PHP, but many of us consider C++ the worst programming language ever invented. If you don't use C++ for a while, you have to constantly look up the rules. It is much better with "cleanly" designed languages.

So, who's "many of us?"

I'm not sure about the worst language but I think it's close to the ugliest syntax. No, it's obviously not my language of choice but I'm quite familiar... I'd hate to see AHK use much more 'C' style syntax... Sorry to veer off-topic...

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004

If I guaranty it in the help file, it will be necessary to abide by it in all future releases, which might reduce performance and flexibility. I'd prefer to go along with what other languages do; so if most of them don't guaranty evaluation order, the same can be stated somewhere in the help file.

Regardless of how other languages are designed, it would tend to make life easier for people writing scripts if it was consistent. I would personally choose easier troubleshooting and a better understanding of expected results over minor performance increases and convenience. That's just me though. Opinions of others may vary...

  • Guests
  • Last active:
  • Joined: --
This may be old news... but anyway,

Does anyone know if other languages guaranty left-to-right evalution order in an expression like func1() + func2()?


I don't know about other languages, but Java does.

From the Java Language Specification:
http://java.sun.com/...sions.html#15.7

The Java programming language guarantees that the operands of operators appear to be evaluated in a specific evaluation order, namely, from left to right.



Laszlo
  • Moderators
  • 4713 posts
  • Last active: Mar 31 2012 03:17 AM
  • Joined: 14 Feb 2005
Thanks for the link! From the same document:

"If an exception occurs, then evaluation of one or more expressions may be terminated before all steps of their normal mode of evaluation are complete". That is, there is no guaranty that all of the sub-expressions are evaluated.

"It is recommended that code not rely crucially on this specification [left-to-right evaluation order]. Code is usually clearer when each expression contains at most one side effect, as its outermost operation, and when code does not depend on exactly which exception arises as a consequence of the left-to-right evaluation of expressions." This should be obvious, but the above discussions show that many programmers don't follow this rule, which is called bad style.

Xander
  • Members
  • 140 posts
  • Last active: Nov 13 2007 08:31 PM
  • Joined: 23 Sep 2007
Sorry, I was the "Guest" ...

That is, there is no guaranty that all of the sub-expressions are evaluated.

While this is true in java, it doesn't really apply to AHK since there is no exception mechanism. Not only are sub-expressions not evaluated, but all statements after the occurance of the exception are not evaluated either. That is, the flow of execution goes to the exception handling block immediately upon the occurance of the exception.

This should be obvious, but the above discussions show that many programmers don't follow this rule, which is called bad style.

I would say it should be minimized, but sometimes it is useful, for instance

j := i + getSomething(++i)

as opposed to

j := i + getSomething(i+1)
i += 1

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

While this is true in java, it doesn't really apply to AHK since there is no exception mechanism.

True, but it does have script errors, which can cause the current "thread" to exit without exiting the script. I suppose it wouldn't be important which expressions get evaluated in case of a script error, though...