Thanks for the reply. As far as I can tell, I have found a difference in Clipper and Harbour in terms of these evaluations. But as I said earlier, I could be completely mistaken. I have done a lot of little tests to check the -z flag but unfortunately I'm not that good at Clipper as one of my friends is. (I'm better at Perl, etc). But if I can demonstrate the problem in a small Hello World type example, I will post it, to try to figure out what is happening, with your help. :) The only reason I bring this up, is because I am trying to compile an old DOS16 app and it is behaving differently on these .or. lines.
Thanks again for reading!!! I have read your informative reply, and will test what you said out for myself to try to figure out what is going on. 2010/1/28 Przemysław Czerpak <dru...@acn.waw.pl> > On Thu, 28 Jan 2010, smu johnson wrote: > > Hi! > > > I noticed the -z switch allows to stop using shortcuts for .and. and .or. > > Clipper conditions. > > Without -z, if I do: > > eval(something) .or. .t. // will recognize that it's already true, and > not > > make the eval > > When -z is enabled: > > .f. .and. eval(something) // will try to eval 'something', despite the > fact > > that .f. already failed. > > Exactly just like in Clipper. > > > ... If what I said is actually true, is there any sort of secondary -z > > switch that can be done to make it simply not be lazy, yet fail on first > > condition? > > It's default behavior. Just simply do not use -z or better use the same > switches as in Clipper. > > > ... If what I said is complete nonsense and complete BS, I will have to > go > > through the code I'm trying to compile that someone else wrote and see > > what's up. By the way, I realize that the above examples are not the > best > > way to do things... and I sure as heck wouldn't do it that way myself. > Just > > trying to get some existing Clipper functioning code to behave the same > way > > in Harbour. > > You mixed two different things which confuse you: > 1. compile time optimizations > 2. lazy boolean expression evaluation > > Both Harbour and Clipper support -z switch to control lazy expression > evaluation. It works in the same way. This code illustrate it: > > proc main() > local f:=.F., t:=.T. > ?; ?? .t. .or. f() > ?; ?? .f. .and. f() > ?; ?? f() .or. .t. > ?; ?? f() .and. .f. > ? > ?; ?? t .or. f() > ?; ?? f .and. f() > ?; ?? f() .or. t > ?; ?? f() .and. f > ? > return > func f() > ?? "[F()] " > return .T. > > compile it with and without -z switch using Harbour and Clipper and > compare results. Please note that when -z is not used then first 4 > expressions are optimized at compile time and next 4 ones are optimized > at runtime. Compile time optimization calculates final result and > replace the code with simple .F. or .T. so F() function is never > execute. It's also Clipper compatible behavior. > Anyhow Clipper does not optimize all expressions (i.e. it does not > optimize <exp> if message is send to it: <exp>:msg()) and cannot strip > parenthesis in optimization process. Harbour does not make any exceptions > here and optimize all end everywhere if it's possible what seems to be > correct behavior. You can add these lines to above test to see the > difference: > > ?; ?? (.t.) .or. f() > ?; ?? (.f.) .and. f() > ?; ?? f() .or. (.t.) > ?; ?? f() .and. (.f.) > ? > ?; ?? ( .t. .or. f() ):classname > ?; ?? ( .f. .and. f() ):classname > ?; ?? ( f() .or. .t. ):classname > ?; ?? ( f() .and. .f. ):classname > ? > > compile it without -z switch and compare Clipper and Harbour results. > If you want to replicate also this Clipper behavior then you can use > -kc switch which disables all Harbour extensions though I cannot promise > that we located all places were Clipper does not make compile time > optimization and added necessary protection for -kc switch. If you will > find sth then please inform us. We try to cover it by -kc switch or > document the difference. Such missing optimizations in chosen places > for me are bugs which should be eliminated to not create some hidden > and not understandable for users exception so I've never tried to make > precise test to detect all such Clipper anomalies. > If you want to read more about compile time optimizations then read > docs/cmpopt.txt > > best regards, > Przemek > _______________________________________________ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson <smujohn...@gmail.com>
_______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
