comp.lang.ada
 help / color / mirror / Atom feed
From: Andre Spiegel <spiegel@inf.fu-berlin.de>
Subject: Re: Depending on passing mechanism
Date: 1997/10/17
Date: 1997-10-17T00:00:00+00:00	[thread overview]
Message-ID: <x2yb3simp9.fsf@moon.inf.fu-berlin.de> (raw)
In-Reply-To: dewar.876965810@merv


Regarding parameter passing mechanisms, particularly in Distributed
Systems, I think there are two possible approaches.

  (1) Leave it up to the programmer to chose by-copy vs. by-reference
      for each subprogram parameter explicitly.

      This way, the programmer can chose the passing mechanism that
      best fits a given situation.  For example, if the call goes 
      across a distribution boundary, by-copy might be preferable, etc.
      Drawback: the decisions for one particular setting, machine,
      compiler might not be optimal for another one.  For example,
      if the call that used to go across a distribution boundary
      becomes a local call at a later stage, by-copy might impose
      an unnecessary cost.  Also, the programmer might not have enough
      information to make the right decision, or simply not care.
      The advantage of this scheme, however, is that program behavior 
      never changes if you move to a different target, compiler, or 
      distribution scenario.  It might become less efficient and 
      sub-optimal, but nothing worse.

      Some of the proposed schemes for CORBA "Objects-by-Value" work
      this way.  Ada does not let you do it -- at least not quite, see
      below.

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

      However, Ada 95 does alleviate this somewhat, through
      "access" parameters.  If the programmer uses "in out", he says
      in fact that he is willing to accept the non-determinism, and
      leaves the optimal decision to the compiler.  But if for some
      reason he needs clear-cut behavior, "access" parameters can be 
      used to guarantee by-reference semantics, no matter what.

      There is no corresponding means to force _by-copy_ semantics in
      Ada 95.  However, one might say that "in out" parameters are 
      conceptually closer to by-copy than to by-reference.  The reason
      is that if an "in out" parameter is passed by reference,
      the callee does not "see" this reference, and hence, cannot
      store it anywhere to create additional aliasing.  If the
      parameter is copied, the _value_ is in fact copied, and the
      reference broken.

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




  reply	other threads:[~1997-10-17  0:00 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-10-13  0:00 Depending on passing mechanism Andre Spiegel
1997-10-13  0:00 ` Matthew Heaney
1997-10-14  0:00 ` Robert Dewar
1997-10-14  0:00 ` Robert Dewar
1997-10-14  0:00   ` Henry Baker
1997-10-15  0:00     ` Geert Bosch
1997-10-15  0:00       ` Robert Dewar
1997-10-15  0:00         ` Brian Rogoff
1997-10-19  0:00           ` Robert Dewar
1997-10-22  0:00             ` Henry Baker
1997-10-15  0:00         ` Robert Dewar
1997-10-17  0:00           ` Andre Spiegel [this message]
1997-10-17  0:00             ` Henry Baker
1997-10-17  0:00               ` Robert I. Eachus
1997-10-17  0:00               ` Jon S Anthony
1997-10-21  0:00               ` Robert A Duff
1997-10-21  0:00                 ` Peter Hermann
1997-10-22  0:00                   ` Robert A Duff
1997-10-22  0:00                     ` Brian Rogoff
1997-10-22  0:00                 ` Henry Baker
1997-10-21  0:00                   ` Robert Dewar
1997-10-22  0:00                   ` Brian Rogoff
1997-10-22  0:00                   ` Jon S Anthony
1997-10-15  0:00       ` Henry Baker
1997-10-15  0:00         ` Jon S Anthony
1997-10-15  0:00         ` Robert Dewar
1997-10-16  0:00         ` Brian Rogoff
1997-10-17  0:00           ` Henry Baker
1997-10-18  0:00             ` Brian Rogoff
1997-10-18  0:00               ` Matthew Heaney
1997-10-19  0:00                 ` Brian Rogoff
1997-10-21  0:00                   ` Robert A Duff
1997-10-22  0:00                     ` Robert Dewar
1997-10-22  0:00                       ` Brian Rogoff
     [not found]                         ` <dewar.877601826@merv>
1997-10-23  0:00                           ` Brian Rogoff
1997-10-23  0:00                       ` Henry Baker
1997-10-23  0:00                     ` Brian Rogoff
1997-10-19  0:00               ` Fergus Henderson
1997-10-19  0:00                 ` Brian Rogoff
1997-10-20  0:00                   ` Fergus Henderson
1997-10-20  0:00                 ` Henry Baker
1997-10-20  0:00                   ` Tucker Taft
1997-10-21  0:00                     ` Geert Bosch
1997-10-18  0:00             ` Fergus Henderson
1997-10-15  0:00     ` JP Thornley
1997-10-21  0:00     ` Robert A Duff
1997-10-22  0:00       ` Henry Baker
1997-10-21  0:00         ` Matthew Heaney
1997-10-22  0:00           ` Simon Wright
1997-10-23  0:00           ` Henry Baker
1997-10-23  0:00             ` Pat Rogers
1997-10-24  0:00             ` Robert Dewar
1997-10-23  0:00         ` Robert A Duff
1997-10-21  0:00   ` Keith Thompson
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox