Re: Call by reference vs. call by value

[dewar@cs.nyu.edu (Robert Dewar)]

Peter Amey said

"This is another Ada feature well covered by the SPARK subset.  The rules
of SPARK (which are checked by the SPARK Examiner) prohibit all cases
of aliasing where program meaning might be affected by the parameter
passing mechanism used. A SPARK program has copy-in, copy-out semantics
regardless of the compiler used to compile it."

Right (or for that matter you can say a SPARK program has by reference
semantics regardless of the compiler used to compile it [for the array
case] :-)

SPARK itself is too restrictive for a lot of general use purposes, but the
kinds of restrictions that it has are worth considering individually in
any coding standard.

I actually like the Fortran rule as to exactly what is and what is not
allowed in Fortran. It is as follows:

  if there are two aliased paths to the same object, it is erroneous (to use
  the Ada terminology) to assign to the object via either path.

That's a very well defined rule. I much prefer it to eithe the bogus rule
in the Ada 83 RM (erroneous if effect differs, but effect never defined),
or to the Ada 95 RM rule that programs are simply non-determinisitc if
their effects depend on the mechanism.

I think the above (Fortran) rule is he one you should have in mind wihile
programming (it is a bit more restrictive than the Ada 95 approach, since
there are progrmas whose effect does not depend on the mechanism, but which
violate this rule), but in practice it is perfectly workable.

You can now if you like follow this up with specific coding rules designed
to prevent this from occurring (e.g. forbidding globally visible objects
to be passed as out or in out parameters to routines that can see the
global, or forbidding the same object from being passed as two separate
parameters if one of them is out or in out).