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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8e64f4db20d57eb5 X-Google-Attributes: gid103376,public From: peterm@senet.com.au (Peter Morris) Subject: Re: Call by reference vs. call by value Date: 1996/07/27 Message-ID: <4tdat5$3jb@clams.camtech.com.au>#1/1 X-Deja-AN: 170473124 references: <31F10E50.726@egr.uri.edu> organization: Camtech (SA) Pty Ltd newsgroups: comp.lang.ada Date: 1996-07-27T00:00:00+00:00 List-Id: bobduff@world.std.com (Robert A Duff) wrote: >In article , >Peter Amey wrote: >>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, but you could equally well say that a SPARK program has by-ref >semantics. SPARK ensures that the two are equivalent by avoiding >aliasing, as you said, and also by avoiding exception handlers. >- Bob The occam programming language which I have been using for distributed control systems also prohibits aliasing. As this seems to be a simple and efficient way to prevent the problems that aliasing can cause I wonder if it might not be a good idea for the full version of ADA95 to prohibit aliasing. > ... and also by avoiding exception handlers. Would it be sensible for an implementation of ADA95 to prohibit aliasing yet allow exception handlers? Peter Morris