Re: and then... (a curiosity)

[stefan-lucks@see-the.signature]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2685 bytes --]

> > (Well, "A and B" also 
> > implies "if B is false, don't care about A", but in a programming language 
> > you can't have it both ways.)
> 
> That is what I learned in my boolean arithmetic classes. It's either
> way. There is no preference that the left parameter if more important
> then the right. A Human seeing "A∧0" won't evaluate A. And if you see
> "f(x)∧g" you would probably evaluate g first as a variable is usually
> easier to evaluate then a function.

True. But, at the logic level, the Ada-statement

  if (X >= A'First) and (X <= A'Last) and (A[X]=Y) then 
    ...
  else
    ...
  end if;

should *not* raise a Constraint_Error if X < A'First or X > A'Last, but 
instead handle the "else" case. 

True enough, at the logic level the same should hold for 

  if (A(x)=Y) and (X >= A'First) and (X <= A'Last) then ... end if;

> It's all about those side effect which make order of evaluation so
> important. Otherwise it should not matter.

The bad thing is that Constraint_Error counts as a valid side effect here.
 
Ideally, the program should check the other branches of the "and" 
expression, and only propagate the exception if none of them evaluates to 
false without raising an exception of its own. 

Consider a programm fragment like

  if X and Y then
    ...
  end if

Assume Y raises a Constraint_Error if X is false. This appears to be a 
common bug pattern in Ada. I have seen this several times in Ada 
sourcecode, and *never* it was the programmer's intention to raise an 
exception if X is false ... except when an exception was raised 
explicitely in the else branch. Even then, the programmers typically 
expected the exception they raised there, not Constraint_Error. 

I admit, we will not get this "ideal" behavoiur in any usable programming 
language. What happens, e.g., if two different exceptions are raised when 
evaluating "A and B"? Which exception should be propagated?

In the absence of this "ideal" behaviour, a short-circuit behaviour of 
"and" and "or" would eliminate a common bug pattern in Ada. I would 
consider it the lesser evil, compared to the current situation.

> Note that once you add:
> 
> pragma Inline (f);
> 
> to the example above things become very interesting for the optimizer
> ;-) (do remember that the optimizer will use goto without shame).

Funny idea! ;-) 

But at the end, there are lots of gotos ("jumps", "branches") in assembler 
code, with or without pragma inline or optimisation.


-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------