From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_05,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!bbn!gatech!csun1!weyrich
From: weyrich@csun1.UUCP (Orville Weyrich)
Newsgroups: comp.lang.ada
Subject: Side effects in Ada functions
Message-ID: <158@csun1.UUCP>
Date: 30 Apr 89 03:03:53 GMT
Distribution: na
Organization: Univ. of GA, CS Dept., Athens
List-Id: <comp.lang.ada>


   My reading of the Ada LRM indicates that functions in Ada may not
have OUT or IN OUT parameters, but may modify non-local variables.

   This means that while a function may not have explicit side effects
(through the use of OUT or IN OUT parameters), it may have implicit
side effects (through the modification of non-local variables or through
calling a procedure which does).

   At best, this strikes me as a curious inconsistency in the design
philosopy of Ada.  DOES THE NET HAVE ANY COMMENTS ON THIS?

   One reason that comes to my mind for allowing functions to have implicit
side effects is that as Ada is presently defined, it is not possible to
reliably detect violations of a "no side effects" rule. IMHO it is better to
not make a rule at all than to make a rule which cannot be enforced. IMHO
the places in the LRM where phrases like "if XXX rule is broken then the
program is erroneous", where XXX cannot be checked at compile time are, worse
than useless.

   Another reason for allowing functions to have implicit side effects is
to facilitate source-level instrumentation of Ada programs.

   This leads to the question "CAN the Ada language definition be modified
in such a way that a prohibition on function side effects can be enforced
without breaking some applications beyond repair?"

   I think that such a modification is both necessary and possible.  I would
propose the following:

   Introduce a new reserved word, NO_SIDE_EFFECTS, which can be placed 
following the formal_part of a procedure_specification to indicate that
non-local variables may not be modified by the procedure.  
It is easy for the compiler to check at compile time that the procedure does 
not directly modify non-local variables, and the compiler can also easily 
complain if a procedure which is declared to have no side effects calls a 
procedure which is not so declared.  
   Functions would be forbidden to modify non-local variables
and would not be allowed to call procedures that were not declared with
NO_SIDE_EFFECTS.  For the RARE occaisions when functions need to have
side effects, the additional reserved word UNCHECKED_SIDE_EFFECTS could be 
placed after the formal_part of the function_specification.  When a function is
declared with UNCHECKED_SIDE_EFFECTS, OUT and IN OUT parameters should be 
allowed.

The above proposal would not badly break existing programs: only those which
used identifiers NO_SIDE_EFFECTS or UNCHECKED_SIDE_EFFECTS, or which used
functions which called procedures or modified non-local variables.  In all
of these cases, the compiler would complain (no mysterious changes in operation
as happened with FORTRAN-66/FORTRAN-77 DO loops), and minor editing would 
suffice to restore proper program operation. I can see no execution penalty
for the proposed changes, nor do I see any great problems for comnpiler
writers.

WHAT DOES THE NET THINK OF MY PROPOSAL? Is it in the spirit of Ada? Should
it be propsed for Ada-9x?  Are there problems which I have not anticipated?
Is there a better way?

-- 
Orville R. Weyrich, Jr.          | UUCP    : ...gatech!csun1!weyrich
Department of Computer Science   | INTERNET: weyrich@csun1.cs.uga.edu
University of Georgia            |
Athens, GA 30602 USA             | MA BELL : (404) 542-1082