Text 41396, 103 rader
Skriven 2006-10-16 20:34:31 av mark lewis (1:3634/12.0)
  Kommentar till text 41237 av Michiel van der Vlist (2:280/5555)
Ärende: smart compilers (was: pi)
=================================
 MvdV>> I have done quit a bit in Pascal programming, but that was a
 MvdV>> long time ago. Before the  IBM PC (clones) dominated the
 MvdV>> market. My compiler went to the museum together with my home
 MvdV>> brew 8 bit system running 6809 FLEX. Haven't written a line of
 MvdV>> Pascal in over fifteen years. So maybe someone will point out
 MvdV>> that it will not complie at all because something is missing...

 ml> don't look at "the language"... look at the code... t'is a mismash of
 ml> at least three...

 MvdV> I would perhaps have been better if you had chosen a specific
 MvdV> language. That way we would not have to make assumptions on how
 MvdV> exactly it interprets this "code". Or in what order it parses...

agreed to a point... but i've not had a compiler in my hands in a year or two
and tatwould be a pascal compiler... the only other thing that might loosely be
considered the same would be on my *nix boxes running "make install" on
numerous source code packages to compile and install them ;)

 ml>>   if (2+2==5) and (3+3==7) then print "EGADS!";

 ml>>   if (2+2==4) or (3+3==7) then print "whew!";

 ml>>   if (2+2==5) or (3+3==6) then print "Whew!";

 ml>>   if (2+2==4) and (3+3==6) then print "WHEW!";

 MvdV>> All these examples are variations of one ande the same thing. A
 MvdV>> constant between the if and the then. The constant is either
 MvdV>> TRUE or it is FALSE. If it is true the print statement will be
 MvdV>> compiled and executed when the object code is run. If it is
 MvdV>> FALSEe, the smart compiler will skip it so nothing will ever be
 MvdV>> printed.

 ml> ahhh... you see one constant where i see three... a large one made of
 ml> two seperate smaller ones... the large one being made of the "and" and
 ml> "or" between the two smaller ones...

 MvdV> An expression made up of only constants is itself a constant. I
 MvdV> was referring to the (boolean) constant that is the result of
 MvdV> evaluating the expression between the if and the then,

O:)

 MvdV>> You want me to do the leg work? Ok...

 MvdV>> EGADS! : skipped
 MvdV>> whew!  : printed
 MvdV>> Whew!  : printed
 MvdV>> WHEW!  : printed

 ml> hey! you didn't take the short-circut like you seemed to be doing
 ml> before... otherwise, you'd have skipped the "Whew!" because the
 ml> evaluation of the first was false and short-circut boolean evaluation
 ml> would have jumped out right there assuming the whole thing was
 ml> false...

 MvdV> Skipping after the first term would have been wrong as it is
 MvdV> followed by an or and what is after the or can change the FALSE
 MvdV> into TRUE.

right... and i believe this is where i've been trying to head for a bit... oh
well, it isn't all that important, anyway...

 MvdV> Mind you: in my original example I was just saying that if what
 MvdV> is between the If end the then evaluates to FALSE, then it is
 MvdV> irrelevant what follow the then and it can be skipped.

in many cases, this may be true... in some others, it may be be what is
actually desired... in those cases, i'd likely call it a design flaw ;)

 MvdV> You are now narrowing it down to the individual terms in the
 MvdV> expression bewteen the if and then but then things become a
 MvdV> little bit more complicated. I never meant to imply that applying
 MvdV> short circuit boolen evaluation *that* way is a good way to
 MvdV> handle things.

thank you... i agree, too, FWTW O:)

 ml>> now, try these...

 ml>>   a=2; b=2; c=5; d=3; e=3; f=7;
 ml>>   if (a+b==c) or (d+e==f) then print "egads!";

 MvdV>> Ah, that is a bit more tough. If it is a *very* smart
 MvdV>> optimising compiler it will be aware that although the terms in
 MvdV>> the if statement are written as variables, the actual values
 MvdV>> are already known at compile time and so the compiler will
 MvdV>> handle it the same as when the actual values were substituted:

 ml> yeah, but we're not studying compiler design so please... don't let
 ml> that bother your noggin', eh? each of those variables could have been
 ml> grabbed by some randomizing function... but i had to have some way of
 ml> presenting the scenerios to you...

 MvdV> Well, then it would have been better to say so instead of just
 MvdV> presenting them as hard coded in the source....

well, ya know that thing about loose lips and sinking ships... hehehe... :)

)\/(ark

 * Origin:  (1:3634/12)