Does Monkey Do Short Circuiting of Conditionals
Monkey Forums/Monkey Programming/Does Monkey Do Short Circuiting of Conditionals
| ||
| NEVERMIND! I realize I should ask this of a target, not of the monkey language itself. :-/ *** Does monkey short circuit conditionals? As an example: [monkeycode] If 1=2 And 2=2 Then Print "Impossible!" Else Print "That's what I thought." Endif [/monkeycode] In the above, since 1=2 is false, it doesn't have to evaluate the rest. [monkeycode] If 1=1 Or 2=3 Then Print "Here, always." Else Print "WRONG!" Endif [/monkeycode] In the above, since 1=1 is true, our conditional is true; there's no need to evaluate 2=3. This applies to any "A and B" or "A or B" conditional. |
| ||
| What problem are you trying to solve? If it's about performance, I think it's not something which will be your bottleneck. |
| ||
| Yes it does with "And" and "Or", but it does not with bitwise & and | for obvious reasons You can safely do: [monkeycode]If mywhatever<>Null And mywhatever.AMethod() >0 Then .... EndIf[/monkeycode] Without worring that the second part of the expression will be executed on a null object instance. |
| ||
| @ziggy - Really? I never knew that - I always put the "if x<>null" in a separate if statement enclosing the next if statement because I was worried that I'd get a null access problem like with MAVs in Blitzplus/Blitz3d...it seems wrong to me to check if something is null and still test a method, property or field of that object in the same if statement as if it is just asking for trouble... |
| ||
| I would say its target dependant, since Monkey translates the If statements into the target If statements... |
| ||
| It's not target dependant. It's how the Monkey compiler handles the operators. From the Monkey wiki: Conditional operators The arguments of conditional operations (And, Or) are first converted to boolean if necessary and the result is boolean. In the case of Or, if the left-hand-side expression evaluates to true, the right-hand-side expression is not evaluated. For example: If car<>Null Or GetSpeed()>10 Then... In the above example, if car is not Null, then the right-hand-side of the Or is not evaluated - ie: the GetSpeed function is never called. In the case of And, if the left-hand-side expression evaluates to false, the right-hand-side expression is not evaluated. For example: If enemies.Count > 0 And HasEnemyInSight() Then ... In the above example, if enemies.Count is <= 0, then the right-hand-side of the And is not evaluated - ie: the hasEnemyInSight function is never called. Reference: http://blitz-wiki.appspot.com/Language_reference#expressions So it is safe to considere them short circuiting conditions is not a target depending thing, and can be used safely. All expression evaluation is (order of operators, data balancing and data conversion, etc.) is handled by the trans compiler, so you are safe. |
| ||
| Shinkiro, yes, I was asking for performance reasons. Thanks for the info, guys (esp. ziggy with the docs reference). :-) |
| ||
| I'm pretty sure it is target dependent no matter what it says in the docs ;) Monkey Code Example: [monkeycode]Function Test1(a%, b%) Print "Test1 start" Return a + b End Function Test2(a%, b%) Print "Test2 start" Return a + b End Function Main() Local x%=5,y%=6 Print "start" If (Test1(10,5)>16 And Test2(10,5)>10) Then Print "Test" Else Print "Fail..." End End[/monkeycode] Which converts to: HTML5: if(bb_untitled4_Test1(10,5)>16 && bb_untitled4_Test2(10,5)>10){C++: if(bb_untitled4_Test1(10,5)>16 && bb_untitled4_Test2(10,5)>10){If the target language does not do short circuiting it will do both Test1 and Test2, say for example if someone created Blitz3D target ;) Its just "lucky" that all the official Monkey targets supports short circuiting :P |
| ||
| Well... I would say if anyone creates a Blitz3D target he/she will have to translate this using nested ifs. The same way trans is handling overloading on languages that do not support it or faking to be strong typed when its using javascript. If the Monkey language supports conditional short circuiting your target should not be an exception. In the same way you would ensure operators execution order is the same no matter which target are you targetting. |
| ||
| Like I said its "lucky" that all the offical Monkey supports short cicuiting as Monkey doesnt do anything itself... |
| ||
| I don't think it's lucky. As instance, Mark decided to not support ^ operator and use a function instead becouse otherwise we would be "out of luck" on language consistence. As this operator has different preference on different languages. As instance, if one would be to make a vb.net target, "And" should be translated to "AndAlso" and "Or" should be translated to "OrElse" operators. That's what he's doing, and he's got this into account, and then he also clearly explains this design on the docs, so I would not say it by luck, but by design. Or you would sincerely considere that a Monkey target that does not behave like all of the other officialy suported targets is reliable, well implemented and not buggy? That's like saying that Monkey does not have its own expression evaluation, so it does not have a custom operators-order execution, its custom type balancing, etc. As instance, it supports automatic conversion to boolean on If, While and any other conditional statement, whilte this is not standard on C# or Java, to name two. One of the strongest points on Monkey is that this data management, type strength, etc. is reliable and consistent between targets. So, honestly, I don't think it's something that just "came out" as a happy coincidence. |
   |