I have the test which has been proven with our Clipper 5.2e running on DOS
of a difference in Harbour.... below is an explanation I received by e-mail:
====== start here
If eval({||devout("hello"),.f.)}) .or. .t.
endif
In Clipper the eval() will process (even though it appears redundant because
.t. will make the IF statement always return .t.
Harbour does not process the eval()
Unfortunately, my code could be scattered with situations where I have used
the Clipper behaviour to do something intentional (as in my search routine).
I will need to look for other places (or more likely wait for things to
break) and change the logic to get around this unless Harbour is interested
in making this fully compatible.
======
Any thoughts? Is it because the guy who showed me this line of code relied
too much on Clipper bugs when programming?
Thanks Przemek
On Thu, Jan 28, 2010 at 3:42 AM, smu johnson <smujohn...@gmail.com> wrote:
> 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>
>
>
--
smu johnson <smujohn...@gmail.com>
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
