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,ab9378bfb1a6fc98,start X-Google-Attributes: gid103376,public From: "Marin David Condic, 407.796.8997, M/S 731-93" Subject: Re: Call by reference vs. call by value Date: 1996/07/25 Message-ID: <96072514363025@psavax.pwfl.com>#1/1 X-Deja-AN: 170148048 sender: Ada programming language comments: Gated by NETNEWS@AUVM.AMERICAN.EDU x-vms-to: SMTP%"INFO-ADA@VM1.NODAK.EDU" newsgroups: comp.lang.ada x-vms-cc: CONDIC Date: 1996-07-25T00:00:00+00:00 List-Id: Peter Amey writes: >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. > While I understand the interest in making language mechanisms secure and predictable, I sometimes wonder about things like this reference/value debate. It seems like a solution desparately seeking a problem. My experience with software bugs (especially in Ada) is that the overwhelming bulk of them are some version of the computer doing what you told it to do, not what you meant for it to do. (The implementer got the logic wrong) Most forms of semanitc induced errors are the kinds of things caught by the compiler (assigning reals to integers without explicit conversion, uninitialized variables, etc.) Those few weird "corner-case" bugs that fall into the category of "the LRM said it was 'implementation dependent' and my implementation bit me on the butt" happen so infrequently (although are annoyingly difficult to find!) as to not be worth the speed penalties imposed by "absolutely provable secure" implementations. I'd favor passing parameters by reference (for speed) over copy mechanisms because in the practical world of "the way programmers *really* program", my experience is thus: 1) You almost never see code (in the real world) where parameter passing mechanisms cause the problems (id est, where compiler "A" would have got it right and compiler "B" got it wrong) 2) Most (Ada) compilers are pretty good at finding the bulk of the parameter-passing problems no matter what the implementation mechanism is through forms of static analysis. (They're also pretty smart about figuring out what's the *optimal* way to pass the parameters, depending on data types.) I think we've learned by now that it doesn't help a language to be syntactically/semantically "perfect" (curing all the "Language Lawyer" problems) at the expense of being slow, cumbersome and late to market. MDC Marin David Condic, Senior Computer Engineer ATT: 407.796.8997 M/S 731-96 Technet: 796.8997 Pratt & Whitney, GESP Fax: 407.796.4669 P.O. Box 109600 Internet: CONDICMA@PWFL.COM West Palm Beach, FL 33410-9600 Internet: CONDIC@FLINET.COM =============================================================================== "Government is not reason. It is not eloquence. It is a force. Like fire, a dangerous servant and a fearful master." -- George Washington ===============================================================================