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: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Depending on passing mechanism Date: 1997/10/15 Message-ID: #1/1 X-Deja-AN: 280857937 References: <622b4t$nhe$1@gonzo.sun3.iaf.nl> X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 876965854 5316 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1997-10-15T00:00:00+00:00 List-Id: Henry suggests <<1. _Always_ pass by reference. This can be forced in C/C++ by certain coding styles. Any aliasing is assumed to be programmer-intended, and has a relatively simple programming model. (You may have to liberally sprinkle 'volatile'-type thingy's around as well.) There is a certain cost, but on modern microprocessors the cost is not exorbitant, and certainly less than the cost of a 777.>> This is VERY difficult in distributed environments where there is no shared memory between caller and callee, and prohibitively expensive. (The 777 rhetoric does not make this problem go away!) It is of course possible to force this same effect in Ada 95, by the use of access parameters, or by-reference types. <<2. _Always_ pass by value. This is really possible only in a 100% functional language like Haskell.>> Nonsense, it is always possible to pass by value, I have no idea what Henry is talking about when he says this. Certainly not Ada. The penalty for passing by value is simply the cost of copying (once for in parameters, twice for in out), but these copies can be prohibitively expensive for large arrays. <<3. Add a new concept to your language: 'linear'/'unique' types. These objects are guaranteed to be singly referenced because this is enforced by the type system. Poof! No aliasing! This concept was pioneered by NIL/Hermes, and has recently been incorporated into some logical (prolog-like) languages and some functional languages ('Clean' from KU Leaven). There is a large and growing body of mathematics called 'linear logic' that puts linear types on a firm theoretical foundation.>> Well certainly not relevant to the issue at hand, and I find the attempt to connect the foundation of this programming language idea, which is shaky, with linear logic, which is not, tenuous at best! <> The contribution was not relevant, and the price is imaginary. Not clear that this has much to do with the actual problem at hand, which is figuring out the desirable semantics for parameter passing in Ada 95. Note incidentally that Ada 95 is very different from Ada 83 here. In Ada 83, an execution whose effect depended on the parameter passing mechanism was erroneous, but effect was ill-defined. In Ada 95, the semantics of programs that depend on the passing mechanism is simply non-deterministic. Note that almost no reasonably written program will depend on the passing mechanism -- indeed the SPARK subset which someone alluded to does not eliminate the non-determinism in a formal sense, it just makes sure that it could not affect the results, which will typically be achieved in most programs in any case.)