Does the LRM permit parameter passing by reference?

Does the LRM permit parameter passing by reference?

[Kevin Simonson]

     I was under the impression that Ada made local copies of parameter
values when a procedure was called.  However my Verdix compiler apparently
does calls by reference when the call is for a string value, as demonstrat-
ed by the script file below.  Notice how the parameter "COPY" (which Ada
won't allow code to alter inside the procedure) changes its value from the
first "put_line" to the second.

     Is it legal for Ada to allow this parameter to change in the middle of
the procedure, or have I found a bug?

                                     ---Kevin

ph^guru} cat reference_demo_p.a
with text_io;

procedure REFERENCE_DEMO_P
is

   ORIGINAL : string(1..3);

   procedure DEMO_P (COPY : string)
   is

   begin

      text_io.put_line (COPY);
      ORIGINAL(1..COPY'length) := COPY;
      text_io.put_line (COPY);

   end DEMO_P;

begin

   ORIGINAL := "abc";
   DEMO_P (ORIGINAL(2..3));

end REFERENCE_DEMO_P;
ph^guru} reference_demo_p
bc
cc
ph^guru} exit
ph^guru} 
script done on Thu Oct  8 08:53:41 1992

Re: Does the LRM permit parameter passing by reference?

[Dan Rittersdorf]

In article <1992Oct9.023807.20641@beaver.cs.washington.edu> simonson@cs.washing
ton.edu (Kevin Simonson) writes:
>     I was under the impression that Ada made local copies of parameter
>values when a procedure was called.  However my Verdix compiler apparently
>does calls by reference when the call is for a string value, as demonstrat-
>ed by the script file below.  Notice how the parameter "COPY" (which Ada
>won't allow code to alter inside the procedure) changes its value from the
>first "put_line" to the second.
>
>     Is it legal for Ada to allow this parameter to change in the middle of
>the procedure, or have I found a bug?
>
>                                     ---Kevin

   Kevin, RM 6.2(7) addresses this issue.  For arrays, records, or task types,
   the LRM gives the implementation the option of pass by reference or
   value.  The Verdix compiler and derivatives pass arrays by reference, 
   and since strings are arrays of character, it is also passed by reference.

   Note that for scalar types (integers, enumerations, floating and
   fixed point types) the LRM explicitly requires pass by value.  You can
   count on it for these types.

   Note also that any program that depends on the parameter passing
   mechanism (for arrays, records, or task types) is declared "erroneous"
   by the LRM, which means that the program is in error, but the compiler
   is not required to detect this dependence and issue an error message.

-- 
-danr
______________________________________________________________________________
  Dan Rittersdorf                           danr@travis.ssd.csd.harris.com
  Harris Corporation, Computer Systems Division, Fort Lauderdale, FL 33309
______________________________________________________________________________
-Won by One        "Sync or be Sunc"

Re: Does the LRM permit parameter passing by reference?

[Michael Feldman]

In article <1992Oct9.023807.20641@beaver.cs.washington.edu> simonson@cs.washing
ton.edu (Kevin Simonson) writes:
>
>     I was under the impression that Ada made local copies of parameter
>values when a procedure was called.  However my Verdix compiler apparently
>does calls by reference when the call is for a string value, as demonstrat-
>ed by the script file below.  Notice how the parameter "COPY" (which Ada
>won't allow code to alter inside the procedure) changes its value from the
>first "put_line" to the second.
>
>     Is it legal for Ada to allow this parameter to change in the middle of
>the procedure, or have I found a bug?
>
You've found a feature. The LRM explicitly allows _structured_ parameters
to be passed either by copy (value/result) or by reference. Scalars must
be copied.

Most compilers indeed pass arrays and records by reference; generally this
is thought to be more efficient, though there is reason to think that
the extra indirection could be more expensive than the time to copy.
Some compilers pass _small_ structures by copy and _large_ ones by
reference. Copying large structures consumes both time and space.

I recall a post a few years ago stating that this flexibility was needed
in order to allow reference passing on single processor machines, but
copying on distributed system, through task entry parameters.

IMHO, Ada has found a nice engineering compromise on the matter of
parameter passing: the abstraction (IN/OUT/IN OUT) is de-coupled from
the implementation (copy vs. reference). This is a clean break from
Pascal, which requires that non-VAR parameters be copied, no matter
how large. This means we had to teach our first-years to pass big
arrays as VAR parametrers, giving the danger of accidental modification,
in order to avoid endless copying.

Rich Pattis did a study once of Pascal texts' code for binary search,
in which much fuss was made over the log N search time, ignoring the
fact that copying the array into the search function was O(N).

Ada doesn't have this problem - we can be pretty confident that realistic
compilers will pass arrays by reference, even if they are IN parameters. 

Nice.

Mike Feldman

------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans wants the fruits of patience -- and they want them now."
------------------------------------------------------------------------

Re: Does the LRM permit parameter passing by reference?

[eru.mt.luth.se!lunic!sunic!nobeltech!dawe]

Having read the debate on allowed parameter passing mechanisms, I would
like to follow up with a related question.

The LRM does (as far as I've understood) allow for an implementation to
skip the "copy-back" of parameters in case an exception is raised preventing
a normal return. What's the impact of this in the real world? Are any 
compilers using this optimization feature?

I am especially interested in the following construct:

    package Smart_Error_Example

       type Status is (Ok, This_Error, That_Error);

       type Data is record          -- Could also be private (normally)
          Current_Status : Status;
          Other_Stuff : ......
       end record;

       procedure Do_Action ( D :  in out Data);

       Any_Error : exception;
    end Smart_Error_Example;

    
    package body Smart_Error_Example is

       procedure Set_Status (The_Status : Status;On_Data : in out Data) is
       begin On_Data.Current_Status := The_Status; end Set_Status;

       procedure Do_Action (D: in out Data) is
       begin
         -- Do something useful
         if That_Error_Detected then
            Set_Status(That_Error, D); -- Set error info for later use
            raise Any_Error;
         end if;
         :
       end Do_Action;
    end Smart_Error_Example;--Unfortunately "erroneous"

This error signaling scheme would be quite suitable for a lot of
applications. It does probably work for most compilers.


Does anyone know a system that fails on the above example?

Can I prevent an optimizer from eliminating the assignment of the 
Current_Status-field by making Set_Status separate??



Thank you for considering these issues.


           Daniel Wengelin
           Systems Designer, 
           NobelTech Systems,
           Naval Sector. 

Disclaimer: This article is on behalf of myself only.

Re: Does the LRM permit parameter passing by reference?

[Michael Feldman]

In article <1992Oct11.162045.5904@nobeltech.se> dawe@nobeltech.se (Daniel Wenge
lin) writes:
>
>Having read the debate on allowed parameter passing mechanisms, I would
>like to follow up with a related question.
>
>The LRM does (as far as I've understood) allow for an implementation to
>skip the "copy-back" of parameters in case an exception is raised preventing
>a normal return. What's the impact of this in the real world? Are any 
>compilers using this optimization feature?
>
For the case of scalar parameters, what you describe as an "optimization"
is in fact REQUIRED by the LRM, sect. 6.2. I quote:

"...after NORMAL completion of the subprogram body, if the mode is OUT
or IN OUT, the value of the formal parameter IS copied back into the 
associated actual parameter."

I have capitalized NORMAL to indicate that if an exception is propagated
from the subprogram, the copyback is NOT done. I have emphasized IS as
well - it does not say "may be."

For the case of composite parameters (arrays, records), it's best to assume
no copyback, because the parameters can (and usually are) passed by
reference. This is discussed in the same section of the LRM.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans wants the fruits of patience -- and they want them now."
------------------------------------------------------------------------