Re: and then... (a curiosity)

[stefan-lucks@see-the.signature]

On Tue, 2 Sep 2008, Ludovic Brenta wrote:

> stefan-lu...@see-the.signature wrote:
> >   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.
> 
> Except that X may be a function returning a different value for each
> call!

On the level of formal logic, there isn't really space for side effects. 

> > The bad thing is that Constraint_Error counts as a valid side effect here.
> 
> And what would be an "invalid" side effect?

A "valid" side effect would, e.g., be changing a global variable. On the 
other hand, a function which raises an exception is essentially a function 
returning some value outside its domain (but inside an extended domain). 
This isn't quite like a side-effect -- only Ada pretends it is. 

> > 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.
> 
> No, because the Constraint_Error (or other exception, or other side
> effect such as logging, assignment to a variable, etc.) may be
> intentional! The compiler does not and should not try to read your
> mind. At least I would find it very disturbing to program in a
> language that would try to "do what I mean, not what I say".

Well, if the program requirements are that the side effects for A and B 
actually occur, I consider it poor programming style if people just write

  if A(X) and B(Y) then ... end if;

IMHO, much better style is the following:

  declare
    Tmp_A: Boolean := A(X);
    Tmp_B: Boolean := B(X);
  begin
    if Tmp_A and Tmp_B then ... end if;
  end;

This makes the programmers intention clear, "if A(X) and B(X)" doesn't. 

> > 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 bug a couple of times and always concluded it was
> *my* fault and that I should have used "and then" to specify that the
> order of evaluation was important. In such situation the mathematical
> "and" (where "X and Y" is strictly equivalent to "Y and X") is not
> what I want.

Right! 

But do you really dispute that following the mathematical conventions 
as much as possible would improve readability? 

> I definitely like the fact that Ada gives me the choice (short-circuit
> or full evaluation) and the means ("and" vs. "and then") to express my
> intent exactly.

A short-circuit "and" (instead of "and then") would not remove that choice 
-- see the "much better style" above. 

In any case, instead of an explicit syntax for short-circuit "and" an 
explict syntax for the rare non-short-circuit cases would be preferable, 
perhaps "if A(X) and all B(Y) then ... end if;".




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