>>>>>Some languages are guaranteed to support left-to-right conditional execution as you outlined in your original message. AFAIK xBASE/VFP is NOT one of them - I don't recall ever seeing any official confirmation of this, either in documentation or by Microsoft. If that's the case there's no need to document this behaviour because you shouldn't be relying on it in the first place.
>>>>
>>>>It's documented in VFP help http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_foxhelp9/html/4fcfebe5-0fbe-41da-96ed-ecaa25a6bf23.asp?frame=true :
>>>>
>>>>"Visual FoxPro evaluates logical expressions from left to right, and only for as long as necessary".
>>>
>>>Thanks for the link! I wasn't aware VFP guarantees this.
>>>
>>>>It may not be true for the SQL conditions though because query optimizer may rearange them.
>>>
>>>Agreed. You and Peter are right, that this deviation from LTR processing support should be documented.
>>>
>>>>>Personally I never use left-to-right conditional execution even in languages that explicitly support it. IMO it makes code hard to understand and is a significant source of nasty bugs. Not to mention that these days, vendors are working hard on optimizing compilers which, if they're at all buggy, will likely have effects like you've seen here. Just say no ;)
>>>>
>>>>I've to disagree with you. I use it all the time. If used properly, it makes code simpler, easier to read and maintain. I never encounter any bugs related to it.
>>>
>>>I think we will have to agree to disagree on this. I believe the following two lines of code should always have the same answer and same effect on the application's environment:

x = foo() AND bar()
>>>x = bar() AND foo()

IMO the only valid reason for ordering logical operands is for speed optimization i.e. if foo() executes faster than bar() and evaluates to .F. often enough to make putting it first worthwhile. This is why LTR processing was devised in the first place.
>>>
>>>For sure, "simpler, easier to read and maintain" is a matter of taste. Sometimes I've been tempted to use LTR, or (more often) inadvertently built logical code that (unknown to me) relied on LTR processing under some input conditions. After refactoring to eliminate reliance on LTR, I have always, without exception, been very glad I did.
>>>
>>>Relying on LTR for flow control is implying nested logic rather than explicitly stating it, which I consider unnecessarily terse and (IMO) hard to read. If you're building complex logic from a truth table it's more difficult to confirm, with LTR, that you've implemented the truth table properly. For me, when the logic is explicitly laid out I find it much easier, 6 months from now, to revisit the code for debugging or enhancement.
>>
>>I can imagine your POV, because you thought that LTR was not a guaranteed part of the language.
>
>Well, the docs say it's supposed to be, but you've already found one instance where it isn't. If you didn't rely on LTR you wouldn't have wasted part of you life dealing with the problem you had.

One day, to be precise.

>The reasons I laid out above are separate from my previously not knowing that LTR is "guaranteed". For me, these benefits accrue whether VFP or another language guarantees LTR support - I still won't use it unless I'm tweaking for maximum performance, and I still arrange logic so (foo() AND bar()) has the same effects as (bar() AND foo()).
>
>The trend these days is towards more and more code optimizations behind the scenes. The VFP SQL engine is a perfect example. Many other language compilers and interpreters optimize as well; even at the processor level modern CPUs employ branch prediction, out-of-order and speculative execution. I imagine compiler and CPU designers consider LTR support a significant limitation on what they can do and would love to chuck it out. It doesn't surprise me that in some circumstances they would do just that (VFP SQL engine), or that in others their optimizations may have bugs that break LTR.

If it will be broken in vfp9+ then that will be a big issue and not many will make the jump.
Code optimization always has to respect the syntax and properties of a language. LTR is just one more language property that has to be respected. It is the language that dictates, not the code optimizer. I don't see any problem ahead.
Personally, I am not sure that vfp's SQL does not respect LTR. The result I got (no LTR in SQL) may well be a bug. In another thread I have asked Aleksey Tsingauz to check it in the vfpteam, but he has not replied. BTW, do you know who took over from John Koziol?



>I think FabioL might have some fun testing here :)
>- LTR in UDFs called from SQL engine
>- LTR in class methods called from SQL engine
>- LTR in UDFs in index expressions used in Rushmore
>- LTR in RI code (Rushmore or not)
>- Potential MTDLL issues
>- Combinations of the above
>- ...