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
