Re: In-Out Parameters for functions

["Robert I. Eachus" <rieachus@comcast.net>]

Hyman Rosen wrote:

> That's not really the point. If I know in micro-detail where a check
> is failing, I could just as easily make it not fail. What I expected
> (which will probably earn me another blast from RE for not getting
> the Ada mindset) was that the reason for l-d checks is to prevent the
> kind of errors you find in C, namely undetected erroneous changes that
> trigger problems at some remove from the place where they occurred.
> It seems to me that the Ada rules allow the same sort of thing to
> happen - if I have a handler at a high level for a language-defined
> error, it's possible that any number of objects may have been left in
> an abnormal state when the exception triggered, and I will encounter
> erroneous (and possibly undetected) behavior at some later point.

First of all, on this point I agree with you that the Ada 95 rules go 
too far.  Fortunately, if you look at the example I posted, most Ada 
compilers are very careful about taking advantage of the 11.6(6) 
freedoms when exceptions can happen.

The real problem is that it is very hard to write a rule that makes 
sense given the way today's CPUs are built.  The CPU will reorder 
instructions at run-time, and only some CPUs will pretend, if an 
instruction causes an interrupt, that the ordering was precise.  I could 
probably reference half a dozen architecture manuals for you, that 
detail exactly how precise and non-precise interrupts are serviced.  But 
it is lots of really boring trivia to sort through to figure out what 
happens in a case that you might care about.  But I do read those 
manuals, thoroughly at least for most SPARC family processors, x86 
processors and now AMD64/IA-32e CPUs.

You have to remember is that the implementations vary, even within a 
processor family, and worse some processors have multiple modes, with 
different interrupt behavior.  So the current (Ada 95) RM rules really 
amount to do what makes sense on the real hardware--because the compiler 
compiles to an ISA, and for many ISAs, the rules change from 
implementation to implementation.

Fortunately, as the program I just posted shows, most compilers still 
obey the old Ada 83 meta-rule:  "Thou shalt not reason from 
erroneousness."  The program as written is (intentionally) erroneous. 
Not causes a bounded error, which is a much more tightly limited case, 
but erroneous.

Would I write code like that 'for real'?  Of course not.  But it doesn't 
prevent me from grumbling about how difficult it can be for a programmer 
to avoid erroneousness in some contexts.

(Technically what you have to do is write subprograms that handle 
exceptions internally as follows:

procedure Foo(...) is
   -- object declarations here should never raise an exception.
   -- put things that can in a nested block.
begin
   declare
      -- potentially problematical variables
   begin
      -- do any additional checking here, but don't assign to any
      -- out or in out parameters.

      -- firewall This is usually a call to some external procedure or
      -- function that is not inlined.  This can be, and often is in
      -- code that I write, a call that is needed anyway.

      -- do any assignments to globals or parameters here.
   exception
      when Constraint_Error =>
      -- fix the problem either by using a different
      -- algorithm, or by a nested call to Foo with modified parameters.
      when others => raise;
      -- or whatever, it is usually Constraint_Error that takes all the
      -- work, and any other exceptions are passed back to the caller.
   end; -- nested block.
end Foo;

All that looks like a lot of work, but it isn't usually.  It is just 
that most programmers Ada or otherwise have no idea of what it takes to 
write a subprogram that actually deals with Constraint_Error instead of 
just renaming it or letting it propagate to the caller.

To give just one example, think about an Inverse function for matrices. 
  There are matrices for which the inverse is well defined, there are 
cases where the matix is singular, and there is a third group of cases 
where the matrix is ill conditioned or stiff.  Often it takes a lot more 
CPU cycles to run the cases which can deal with ill-conditioned or stiff 
matrices, so you really do want to try say, simple LU decomposition first.

If you do go to that effort, putting the firewall call in is no big 
deal.  Writing the code so that you can begin over when needed is often 
more work, but in this case you are not inverting the matrix in place 
(unless you pass the matrix with an access parameter).

Now if anyone wants to submit a suggestion to Ada-Comment suggesting 
that there actually be a language defined procedure Firewall that does 
nothing but what its name implies, fine.  Personally I find it easy 
enough to have my own version around and call it.

-- 
                                           Robert I. Eachus

"The only thing necessary for the triumph of evil is for good men to do 
nothing." --Edmund Burke