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,29fe9a340e0d180d X-Google-Attributes: gid103376,public From: hbaker@netcom.com (Henry Baker) Subject: Re: Depending on passing mechanism Date: 1997/10/17 Message-ID: #1/1 X-Deja-AN: 281278849 Sender: hbaker@netcom5.netcom.com References: <622b4t$nhe$1@gonzo.sun3.iaf.nl> Organization: nil Newsgroups: comp.lang.ada Date: 1997-10-17T00:00:00+00:00 List-Id: In article , Andre Spiegel wrote: > (2) Let the compiler make the decision. The programmer specifies > the "intent" of the parameter in a more abstract way. This is > what Ada always did, through "in", "out", and "in out". The > advantage is higher efficiency. Passing mechanisms may be > employed automatically in an optimal way to make use of hardware > characteristics, and to support given distribution scenarios. > The drawback is non-deterministic program behavior, if only in > rare circumstances that could well be called pathological. > I think this way of handling parameters makes Ada particularly > suitable for distributed systems with a high degree of transparency, > i.e. where the programmer does not necessarily know where distribution > boundaries will be at run-time. > > Andre Spiegel > Free University of Berlin My paper (ftp://ftp.netcom.com/pub/hb/hbaker/LimitedRobbery.html) shows how copy-in, copy-out semantics violates the notion of limited private types, and is therefore a dangerous idea. I don't expect to change anyone's mind, but you should be aware that Ada has serious flaws that are visible to those outside the Ada community, although (apparently) are not visible to those within the community.