parameter passing

parameter passing

[David Guaspari]

Here's why I asked whether it would be reasonable to assume that
parameters of the same type are passed in the same way.  My problem is
reasoning about the values of out or inout parameters of composite
types after exceptional exit.

There are useful, simple cases in which we know how to write the
intended programs (in a natural way) and convince ourselves that
they're correct.

1. Example: Consider 

  procedure add_item(comp: in out composite_type, i: item_type)

part of whose specification is

  If i is an inappropriate item, then raise the exception
  INAPPROPRIATE_ITEM and leave comp unchanged.

If comp is passed by copy, then this part of the specification is
satisfied free of charge, so (at least as far as the given spec is
concerned) we can safely reason about add_item under the assumption
that comp is passed by reference.

2. Generalizing the example: 

What the example really shows is that it's possible to reason easily
about *invariant properties* of writable composite parameters -- i.e.,
about specifications like

  (*)  If some_exception is raised then (in the resulting exit state) 
       comp still satisfies some_property_it_satisfied_on_entry

It takes modest care to formulate "comp still satisfies ..." correctly. 

3. Generalizing too far: 

I'm involved in designing a specification language for Ada programs.
It permits you to say things like (*), but not to state any other
kinds properties of the value of comp upon exceptional exit.
Naturally, we want the class of permitted invariant properties to be
as general as possible (so long as we can still reason about them
easily).  Under Ada's rules, we're going too far if we permit the
invariant to be a joint property of two writable parameters, e.g. (for
the case in which composite_type is an array type (or, in the second
case, an array type with discrete components))

    if comp1 and comp2 are permutations of one another upon entry,
    then they are still permutations of one another upon exceptional
    exit

or

    the lexicographic ordering of comp1 and comp2 is the same on
    exceptional exit as it was on entry

For specifications like these, we can safely pretend that comp1 and
comp2 are passed by reference only if we are entitled to assume that
they're passed by the same mechanism.  

Hence my question.


David Guaspari
oravax!davidg@cu-arpa.cs.cornell.edu
davidg%oravax.uucp@cu-arpa.cs.cornell

parameter passing

[Riyaz Mansoor]

i want to pass a generic package as a parameter to another genric package.

eg:

with gen1_pack;
with gen2_pack;

procedure main is
    package gen1 is new gen1_pack;
    --how do i declare the gen2_pack with gen1 as a parameter?
begin
end;

also how would the code look like in gen2_pack which actually accepts the
gen1 package as a generic "paramter" ?

thanks


----------------------------------------------------

Re: parameter passing

[Richard D Riehle]

In article <88gqg5$4a8$1@bunyip.cc.uq.edu.au>,
	"Riyaz Mansoor" <s800032@student.uq.edu.au> wrote:

>i want to pass a generic package as a parameter to another genric package.
> --how do i declare the gen2_pack with gen1 as a parameter?
>also how would the code look like in gen2_pack which actually accepts the
>gen1 package as a generic "paramter" ?

The following Sort Utilities package is an abbreviated version of the original
package with removal of a lot of comments.  It should be easy to read.

-- =========================================================
-- Sort_Utilities.Ads              Richard Riehle, AdaWorks
--
-- This package contains a set of generic sort routines that
-- can be instantiated for the sorting of an unconstrained
-- array.  The Big-O notation associated with each sort is a
-- kind of design metric that represents the relative performance
-- of each algorithm.  
-- =============================================================
package Sort_Utilities is

  generic
    type Data is private;
    type Index is (<>);
    type Data_Set is array(Index range <>) of Data;
    with function Is_Greater (Left, Right : Data) return Boolean;
    with function Is_Equal   (Left, Right : Data) return Boolean;
  package Sort_Signature is end Sort_Signature;

  generic
    with package Signature is new Sort_Signature(<>);
  procedure QuickSort(The_Data : in out Signature.Data_Set); -- Note the dot notation

  generic
    with package Signature is new Sort_Signature(<>);
  procedure BubbleSort(The_Data : in out Signature.Data_Set);

  generic
    with package Signature is new Sort_Signature(<>);
    use Signature;                                          -- Note the use clause
  procedure InsertionSort(The_Data : in out Data_Set);      -- Dot notation not required

  -- More kinds of sort algorithms.

end Sort_Utilities;

The generic sort procedures each have a generic formal package parameter using
a signature immediately enclosed in the same package specification.  The following
little procedure, some code deleted for pedagogic purposes, demonstrates how to
instantiate one of these sort routines.  

with Sort_Utilities;
procedure Test_Utilities is

  type Stock is record
     Data : String(1..20);
     Key  : Positive;
  end record;

  type Stock_Array is array(Positive range <>) of Stock;

  function "="(L, R : Stock) return Boolean is
  begin
     return L.Key = R.Key;
  end "=";

  function ">"(L, R : Stock) return Boolean is
  begin
     return L.Key > R.Key;
  end ">";

  package Stock_Signature is new Sort_Utilities.Sort_Signature
                   (Data => Stock,
                    Index => Positive,
                    Data_Set => Stock_Array,
                    Is_Equal => "=",
                    Is_Greater => ">");

  procedure Stock_Sort is new Sort_Utilities.QuickSort
                   (Signature => Stock_Signature);

begin
  null;  -- Of course you will want some actual code here. :)
end Test_Utilities;

In the body of the Sort_Utilities, you will refer to each signature parameter with
dot notation, unless you prefer a use clause, as we did for InsertionSort.

Hope you find this useful.

Richard Riehle

Re: parameter passing

[Ehud Lamm]

The Safe_Io example which can be found on the language&techniques section
of AdaPower shows how you can use a signature package. In this particular
case, we use a signature package to  combine a types and its I/O routines.

The example includes an example instnatiation.

HTH

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

Re: parameter passing

[stt]

Re: Assumptions about parameter passing

No, it is not a safe assumption.  In a distributed address
space (such as the 1750A expanded memory model), the compiler
will copy composite parameters which would not be addressible
in the called routine's address space, whereas those
which are addressible may be passed by reference.

Another case is where one formal parameter is constrained, and the other
is unconstrained or simply has a different
constraint (though both are of the same type).  Many compilers
pass "short" composite objects by copy, and longer or unconstrained
ones by reference.

In any case, I am curious why you care.  It would be
useful to have specific examples of where this kind
of assumption about parameter passing
would be useful, since limiting compiler flexibility
can severely interfere with efficiency.
However, it is also the case that variability can
make certain kinds of program proofs more complicated
(though not always! Sometimes it is easier to prove
something using a non-deterministic model than
a deterministic model).

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138

Re: parameter passing

[Michael Feldman]

In article <1569@oravax.UUCP> davidg@oravax.UUCP (David Guaspari) writes:
>Certain kinds of reasoning about Ada subprograms that terminate by
>raising exceptions are considerably simplified if one is allowed to
>make the following assumption:
>
>   If a and b are actual parameters to some call of subprogram P,
>   and a and b are of the same type, then that call passes them
>   in the same way (either both by copy or both by reference).
Scalars are passed by copy - always. Structures and arrays can be
passed by reference or by copy. I can speak for a few compilers I know
(but don't remember which is which) - many systems will gauge which way
to pass based on the size of the parameter. That is, arrays known to be 
"small" will be copied, but arrays not known to be small - either known to
be large, or unconstrained and of unknown size - will be passed by reference.
Since constrained objects of an unconstrained type have different subtypes
but the same type, what you say holds true in my experience. I can't imagine
why different objects of the same type should be passed differently. But
then again, there are a lot of imaginable things _I_ can't imagine.
Great question for language lawyers!
---------------------------------------------------------------------------
Prof. Michael Feldman
Department of Electrical Engineering and Computer Science
The George Washington University
Washington, DC 20052
+1-202-994-5253
mfeldman@seas.gwu.edu
---------------------------------------------------------------------------

Parameter Passing

[Jon Humphreys]

I'm currently trying to learn Ada by translating a program written
in BASIC (my employer's choice, not mine), and I've got a fairly
fundamental question: when passing parameters from one package
to another, is it possible to simulate something like a FORTRAN
common block by placing variables in a package and then 
using the package whenever I need to access/modify the variables? For
example, consider the following hierarchy:

				main
				 | 
			--------------------
			|  		   |
			A		   B
					---|---
					|     |
(B, C, and D are a package)		C     D

If a set of variables were used in procedures A and D, would it
be possible to create a package containing these variables and 
then include them in procedure A and D? Or should all the variables
be declared in main and then passed as parameters to A and B, and then
from B to D (this seems inefficient)? I guess what I'm asking is, which 
way would be considered correct in Ada? (Currently, we don't even have a 
compiler, so there isn't any way for me to test this kind of thing.)

Thanks for any help, 

jon

Re: Parameter Passing

[William Thomas Wolfe,2847,]

From article <1116@bdmrrr.bdm.com>, by jon@bdmrrr.bdm.com (Jon Humphreys):
> I'm currently trying to learn Ada by translating a program written
> in BASIC (my employer's choice, not mine), and I've got a fairly
> fundamental question: when passing parameters from one package
> to another, is it possible to simulate something like a FORTRAN
> common block by placing variables in a package and then 
> using the package whenever I need to access/modify the variables? 

    Sure, it's easy.  Just set up:

      package Global_Variables is

         First_Variable  : First_Variable_Type := Initial_Value;

         Second_Variable : Second_Variable_Type;

         -- etc...

      end Global_Variables;

   Then simply with the package whenever you need it; just remember 
   to qualify all references with the package name, e.g., 

      Global_Variables.First_Variable := whatever...;

   Now as to whether or not this is a good idea, I think *you* already
   know that the application should be redesigned rather than translated
   literally; so just post your boss's e-mail address and we'll...   :-)


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

parameter passing

[Eric Marshall]

	The LRM 6.2:6 says that access variables have to be
passed via copy-in. What benefit does this have for IN parameters?
How could a user detect if a compiler did not do this?

Thanks in advance.


Eric Marshall
System Development Corporation, a Burroughs Company
P.O. Box 517
Paoli, PA. 19301
(215) 648-7223

USENET: sdcrdcf!burdvax!eric
        {sjuvax,ihnp4,akgua,cadre}psuvax1!burdvax!eric
ARPANET: PAYTON@BBNG

Re: parameter passing

[Geoff Mendal]

The answer to this question can be found in Ichbiah's
"Ada Rationale" draft, which by the way, will be coming
out in published form "soon".  (This word comes from
Ichbiah himself, speaking at a local SIGAda meeting
last Tuesday in Silicon Valley.)  See section 8.2.2
of the "Ada Rationale".  I'll summarize it here for
those who don't have a copy.

Consider the following procedure to delete an element from
a doubly linked list:

  type Element;
  type Ptr is access Element;
  type Element is
    record
      Prev,
      Succ  : Ptr;
      Data  : some_type;
    end record;
  E : Ptr;
  procedure Delete (P : in Ptr) is
  begin
    P.Succ.Pred := P.Pred;
    P.Pred.Succ := P.Succ;
    P.Succ := null;
    P.Pred := null;
  end;

A call to this procedure of the form

  Delete (X);

will work regardless of the parameter passing mechanism.  However,
consider now the call:

  Delete (E.Pred);

where the linked list, before the call, has the state:

  Element:        A  B  C  D  E  F

  succ:           B  C  D  E  F  ...
  pred:          ... A  B  C  D  E

If the parameter passing mechanism is by copy, then the desired
effect is achieved, but pass-by-reference will not work (the list
ends up in a state of "chaos").  You can work out the details
yourself, or see Ichbiah's pictures.

The language designers chose to make pass-by-copy the rule to
eliminate problems such as the one above.  Access types allow
the programmer to create and manage aliases.  It was the view
of the language designers not to have parameter passing create
more aliases of which the programmer is unaware.  Another
problem with pass-by-reference is in achieving the desired
semantics on distributed systems with multiple address spaces.

I'll let you ponder these ideas, and leave you with perhaps a
tangential question (the answer for which is similar to this
question):

  Why, for mode out access type parameters, does Ada require
  copy-in of the actual access value?  Obviously the formal
  cannot read the actual's value, so why require that it be
  copied in?  (somewhat of a trick question)

gom
-------

Re: parameter passing

[Mats_Ohlin_FOA2]

This is of good case for arguing that Ada should have (had?)
procedures inside records, much the way SIMULA has.
If so, you could just code E.Delete (or E.Pred.Delete) with
no problems with parameters. It would also given Ada the
possibility to be more "functional". Consider e.g.
a system for matrix handling - a possibility to
code A:= B.Inverse.Transpose; would give much clearer
code than Transpose(A,Invert(B)) with parameters in out.
Something for Ada88 (90?)?

Mats_Ohlin_FOA2%QZCOM.MAILNET [@MULTICS.MIT.EDU]