Re: Collective response to := messages

[billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)]

From article <10960@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
> |> They are not the least bit equivalent, for several reasons.  The most
> |> obvious reason is that an implementation is free to pass composite
> |> parameters by reference, although no implementation can "assign by
> |> reference". 
> |
> |    Sure, for "in out" mode.  But for modes "in" and "out", failure to
> |    use the ADT's assignment procedure causes major problems:
> |
> |      "out" mode:  Programmer assigns the parameter a value, and the
> |                   value is copied back to the actual parameter.  
> |                   Unfortunately, the portions of the actual parameter
> |                   which were formerly accessible by pointers are now
> |                   uncollectable garbage.
> |
> |       "in" mode:  Programmer assumes that this is a "pass by value"
> |                   and makes modifications.  Since ADT contains pointers,
> |                   modification echoes through to the actual parameter.
> |                   Programmer could also invoke DESTROY, blowing away
> |                   major portions of the actual parameter.
> 
> I'm terribly confused.  Are we still talking about Ada?  With this talk
> about parameter passing invoking source-level assignment, I'm not so sure.
> I'm not sure what your "out" mode comments refer to, but maybe you're
> confusing what access values (pointers) can point to in Ada, or maybe you're
> confusing how access values are passed as parameters in Ada--access values are
> ALWAYS copied IN to their respective places in formal parameters, EVEN for
> mode "out" formals.  

     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.
 
> Your "in" mode comments are also vague.  First of all,
> "good" Ada programmers assume nothing about parameter passing behavior.

     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.

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


                                          Bill Wolfe

                                  wtwolfe@hubcap.clemson.edu