Re: Collective response to := messages

[leake@cme.nbs.gov (Stephe Leake)]

In article <3734@hubcap.UUCP> billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) writes:

	OK.  Envision an ADT which just happens to be implemented as a pointer
	to a descriptor, which probably has more pointers to the "value".  Now
	our ADT user wishes to transfer an ADT "out".  The ADT user has no idea
	how the ADT is implemented.  Now when the procedure was invoked, let's 
	assume that the ADT supplied as an actual parameter had some value;
	hence, the pointer which represents the "ADT type" is not null, and 
	in fact constitutes the only known method for accessing a substantial
	amount of utilized memory.  Our ADT user sends the value "out", and
	Ada implements this by copying the value of a single pointer.  The old
	pointer value associated with the actual parameter is lost forever,
	and all the stuff it pointed to is now garbage.

This is precisely the reason for limited private types; only functions
provide by the ADT package may have out parameters of the limited
type, so the ADT programmer can ensure correct behaviour, including
garbage collection and copying. This is a much simpler solution than
forcing parameter passing to use the ADT assignment operator.

	Anything which is passed as an "in" parameter should be treatable as
	something which was passed in by value.  Anything which is passed as
	an "in out" parameter should be treatable as something which was passed
	by reference.  Anything which is passed as an "out" parameter should
	be treated as the target of a pass by value in the "outward" direction.


	If nothing can be assumed about parameter passing behavior, then 
	parameter passing is just too vaguely defined, and needs to be clarified.

The program should be independent of the choice of parameter passing
implementation. (LRM 6.2 (7) says so).  What can be assumed about
parameter passing behaviour is precisely what the LRM says (mostly in
6.2,3,4); no more, and no less. If you want different semantics, use a
limited type (and document the semantics in the package spec).

   > Second, an access value can be passed as a parameter, in which case the
   > language is concerned only with the access value during parameter passing,
   > NOT with the object designated by the access value.

	When what is being passed is known to the user as an access value,
	this is precisely what the programmer expects.  When what is being
	passed is known to the user as an ADT, this sort of behavior is
	totally counterintuitive.  It violates the abstraction.

Once again, this is why limited types are available. It is up to the
ADT implementor to insure that abstraction violations are not
possible. This is not always easy.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899