Re: Depending on passing mechanism

[dewar@merv.cs.nyu.edu (Robert Dewar)]

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 NIL/Hermes people tried to get people in the Ada community to pay
  attention, but they were completely ignored, and Ada95 suffered for it.>>

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.)