eachus@mitre-bedford.ARPA (Robert Eachus) (12/08/88)
In article <10963@ulysses.homer.nj.att.com> dsr@hector.UUCP (David S. Rosenblum) writes: >In article <3734@hubcap.UUCP> wtwolfe@hubcap.clemson.edu writes: >| If nothing can be assumed about parameter passing behavior, then >| parameter passing is just too vaguely defined, and needs to be clarified. > >You'll have to take this up with the Ada Language Maintenance Committee. >The language designers, and many Ada programmers, believe it to be as >clearly defined as it needs to be so that portable programs may be written. The Ada Rapporteur Group (the current instantiation of the Ada LMC), does NOT feel that it is as clearly defined as it needs to be. AI-178 Passing parameters by reference, was discussed again at the meeting in October, and although we are close to a consensus, the AI is being rewritten for the February meeting. Basically, the AI defines when it is legal to pass parameters by reference, and what it means to do so. In spite of some of the comments here, there are many cases where non-scalar parameters must be passed by copy to conform to Ada semantics. However, there are some questionable cases which this AI attempts to resolve. For example, if A and B are arrays stored in adjacent locations in memory, is it legal to pass A&B by reference? The AI says no, but currently allows A(1..10) to be passed by reference, and is being reworded to require (A) to be passed by copy. If this issue is important to you, get the current version from ajpo.sei.cmu.edu, and send any comments to ada-comment@ajpo.sei.cmu.edu. Please, read the entire AI and any current comments before commenting on it yourself. This is an issue where programming style and what users think are important, but there are some real gotchas that have to be taken into account. Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...